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ABSTRACT 


Semi-Automated  Forces  (SAFOR)  are  a  key  component  of  the  Distributed 
Interactive  Simulation  (DIS)  virtual  environment  A  SAFOR  capability  is  being  developed 
for  the  Gose  Combat  Tactical  Trainer  (COT)  production  program,  which  is  pan  of  the 
larger  Combined  Arms  Tactical  Trainer  (CATT)  effort.  Panel  discussions  were  held 
27-29  October  1993  on  the  development  of  CCTT/CATT  SAFOR  and  its  ability  to 
exchange  ideas  and  products  with  all  DIS  programs.  The  panel  concluded  that  the  widest 
possible  community  should  develop  and  share  owneiship  in  a  CCTT/CATT  SAFOR 
product  More  specifically:  (1)  The  same  SAFOR  products  can  and  should  be  used  to 
support  both  the  research  and  development  and  the  user  community;  (2)  Two 
computationally  separate  SAFOR  lines  of  development  one  based  on  an  Ada  environment 
and  one  based  on  a  C  environment  would  inevitably  develop  discrepancies,  become 
insufficiently  coordinated,  and  should  not  be  pursued;  (3)  The  research  and  development 
community  and  other  interested  communities  are  unlikely  to  have  either  the  resources  or 
inclination  to  migrate  to  an  Ada  programming  environment;  (4)  Products  from  CCTT/ 
CATT  SAFOR  development  should  be  made  as  accessible  and  adaptable  as  possible — 
higher  priority  should  be  given  to  accessibility  and  adaptability  than  to  life-cycle 
maintainability;  (5)  CCTT/CATT  SAFOR  development  should  be  pursued  using  a  C  and/or 
C++  programming  environment 
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OVERVIEW 


A.  BACKGROUND 

Sam-automated  forces  (SAFOR)  are  a  key  component  of  the  Distributed  Interactive 
Simulation  (DIS)  virtual  environment  As  the  use  of  DIS  has  increased,  so  also  has  the 
number  of  programs  requiring  high  quality  SAFOR.  Program  officers  and  research  and 
development  sponsors  have  responded  to  this  demand  by  funding  independent  SAFOR 
developments,  each  based  on  their  separate  assessments  of  needs  and  perceptions  of  the 
electronic  battlefield.  The  DoD  environment  that  evolved  during  the  Cold  War  era  allowed 
for,  and  even  encouraged,  these  independent  developments.  However,  the  post  Cold  War 
environment  of  declining  budgets  requires  different  strategies.  The  exchange  of  ideas  and 
products  to  promote  efficient  development,  lower  costs,  and  transfer  of  knowledge  among 
interdependent  programs  is  now  at  a  premium. 

Two  major  SAFOR  development  programs  are  ModSAF  and  Close  Combat 
Tactical  Trainer  (COT)  SAFOR.  ModSAF  provides  an  open,  modular  architecture  that 
allows  users  to  develop  their  own  SAFOR  entities  and  exchange  them  with  developers  and 
users  in  other  programs.  ModSAF  is  proving  to  be  an  excellent  product,  but  it  was 
intended  more  for  a  research  and  development  environment  than  for  production 
environment  COT  SAFOR  is  being  developed  as  a  product  under  the  COT'  production 
program,  which  is  part  of  the  larger  Combined  Arms  Tactical  Trainer  (CATT)  effort 
COT  SAFOR  is  intended  to  be  the  core  SAFOR  for  follow-on  CATT  development  and  a 
source  of  transportable  modules  that  can  be  ported  to  other  programs  so  that  they  can  take 
advantage  erf  the  CATT  investment 

Development  of  SAFOR  is  not  limited  to  the  ModSAF  and  COT  programs,  nor  is 
it  limited  to  training  applications.  Both  SAFOR  and  DIS  are  expected  to  serve  many 
communities,  including  those  that  support  acquisition,  test  and  evaluation,  tactical  doctrine 
development  and  various  user  communities.  The  exchange  of  ideas  and  products  among 
these  programs  is  a  core  issue  for  all  concerned  with  the  development  and  application  of 
DIS. 
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To  address  this  issue  and  help  ensure  coordination  and  cooperation  among  ail  lines 
of  SAPOR  development,  the  Program  Manager,  CATT,  convened  a  panel  to  consider  the 
following  questions: 

1  Can  the  same  SAFOR  products  (including  specifications,  functional 
description,  and  software)  support  both  the  research  and  development 
community  and  the  user  community  (including  the  education,  training, 
doctrine,  analysis,  test  and  evaluation,  production,  and  logistics  communities)? 

If  yes,  what  are  the  products,  what  attributes  should  they  possess,  and  how 
should  they  be  exchanged  among  users? 

If  no,  are  there  sub- products  car  components  that  can  be  used  by  both  the  R&D 
and  user  communities?  If  there  are,  what  are  these  components  and/or  their 
characteristics? 

2.  What  software  approach  (language,  system,  shells,  tools,  etc.)  should  be  used 
for  CCTT  SAFOR  considering  the  needs  of  both  the  research  and  development 
community  (flexibility,  ease  of  use,  etc.)  and  user  communities  (controlled 
configuration,  life  cycle  maintainability,  reliability,  etc.)? 

3.  What  products  are  available  from  other  programs,  such  as  ModSAF  and  the 
Institute  for  Simulation  and  Training's  Computer  Generated  Forces  (1ST 
CGF),  that  can  be  used  directly  or  in  some  re-engineered  form  to  aid  in  the 
development  of  the  CCTT  SAFOR? 

4.  What  strategy  or  specific  steps  should  the  Program  Manager,  CATT,  take  to 
build  community  consensus  and  to  produce  a  product  that  will  support  CATT 
programs  other  than  CCTT? 

5.  Taking  into  consideration  all  the  above,  what  strategy  or  specific  steps  should 
the  Program  Manager,  CATT,  take  to  implement  the  CCTT  SAFOR? 

The  panel  was  asked  to  address  these  questions  specifically,  but  its  discussions 
were  not  limited  to  them.  Basically,  the  discussions  were  intended  to  provide  candid, 
technical  interchange  among  groups  concerned  with  development  of  SAFOR  capabilities 
for  CCTT  and  CATT. 

The  discussions  were  held  27-29  October  1993,  in  Orlando,  Florida,  in  accord  with 
the  following  agenda: 
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Wednesday,  27  October 

0800-1000  Introduction  and  Discussions  with  PM  CATT 
1000-1030  Break 

1030-1200  Discussion  of  DMSO  SAFOR  Survey  (Organized  by  MITRE  Corporation) 
1200-1300  Lunch 

1300-1500  Discussion  of  ModSAF  (Organized  by  Loral  Corporation) 

1500-1530  Break 

1530-1730  Computer  Generated  Forces  and  C  to  Ada  conversions  (Organized  by  the 
Institute  for  Simulation  and  Training,  University  of  Central  Florida) 

Thursday,  28  October 

0800-0900  Plans  for  future  SAFOR  capabilities  and  development  (Presented  by  ARPA) 

0900-1200  Current  CC1T  status  and  plans  (Organized  by  IBM  Corporation) 

1200-1300  Lunch 

1300-1530  Continued  discussions  of  CCT1  status  and  plans 

1530-1730  Discussions  among  panel  members  and  clarifications  of  information 
presented  earlier 

Friday,  29  October 

0800- 1100  Discussions  among  panel  members  and  preparation  of  recommendations 

1 100-1200  Debrief  to  Program  Manager,  CATT 

The  discussions  were  open  during  the  information  briefings  (i.e.,  from  1030  on 
Wednesday  to  1530  on  Thursday).  Other  times  were  reserved  for  the  panel.  Hard  copies 
of  the  slides  used  for  the  presentations  are  included  as  Appendices  to  this  document. 

The  six  members  of  the  panel  were: 

Dr.  Philip  Anton 
MITRE  Corporation 

Dr.  Peter  Brooks 
Institute  for  Defense  Analyses 

General  Paul  Gorman  (USA,  Ret.) 

Cardinal  Point,  Inc. 


Dr.  John  Laird 
University  of  Michigan 

Dr.  Duncan  Miller 
MIT  Lincoln  Laboratory 

LTC  Robert  Richbourg,  USA 
U.S.  Military  Academy,  West  Point 

Prior  to  the  meeting,  the  panel  members  received  a  read-ahead  package  that 
contained: 

•  Brooks,  R.A.,  Buchanan,  B.G.,  Lenat,  D.B.,  McKeown,  D.M.,  and 
Fletcher,  JD.  Panel  Review  of  the  Semi-Automated  Forces  (IDA  Document 
D-661).  Alexandria,  VA:  Institute  for  Defense  Analyses,  September  1989 — 
Summary  Only- 

•  Booker,  L.,  Brooks,  P.,  Garrett,  R.,  Giddings,  V.,  Salisbury,  M.,  and 
Worley,  R.  1993  DMSO  Survey  of  Semi-Automated  Forces.  Washington, 
DC:  Department  of  Defense  Modeling  and  Simulation  Office,  30  July  1993. 

•  Report  of  the  Defense  Science  Board  Task  Force  on  Simulation,  Readiness, 
and  Prototyping.  Washington,  DC:  Office  of  the  Under  Secretary  of  Defense 
for  Acquisition,  January  1993. 

•  SAFOR  Trade  Study  Results.  Orlando,  FL:  Project  Manager  Combined  Arms 
Tactical  Trainer,  U.S.  Army  Simulation,  Training,  and  Instrumentation 
Command,  15  March  1993. 

•  A  Modular  Solution  for  Semi-Automated  Forces:  ModSAF,  An  Overview. 
Cambridge,  MA:  Loral  Advanced  Distributed  Simulation  (Undated) — Briefing 
(Paper  Copy  of  Overhead  Transparencies). 

•  PIDS  Revision  A:  Requirements  Allocated  to  All  or  SAF  Computer  Software 
Configuration  Items  ( CSCI ).  Orlando,  FL:  Project  Manager  Combined  Arms 
Tactical  Trainer,  U.S.  Army  Simulation,  Training,  and  Instrumentation 
Command,  26  August  1993. 

Members  of  the  panel  were  requested  to  document  their  impressions,  suggestions, 
and  recommendations.  Their  comments  are  included  as  Appendix  A:  A  summary  of  their 
comments  follows.  It  is  divided  into  three  sections:  Findings,  Recommendations,  and 
Conclusions. 

B.  FINDINGS 

Presently  the  CCTT  SAFOR  has  been  designed  as  a  re-engineered  version  of 
ModSAF  to  be  developed  using  an  Ada  programming  environment.  ModSAF  itself  and 
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nearly  all  SAFOR  applications  have  been  developed  using  C  programming  environments. 
A  major  decision  for  PM  CATT  is  whether  to  pursue  an  Ada-based  CCTT  SAFOR  or  to 
require  more  compatibility  with  the  existing  C-based  development  of  ModSAF.  This 
decision  impacts  die  development  of  SAFOR  capabilities  across  all  applications  and 
concerns  all  questions  raised  by  PM  CATT  for  this  panel 

The  following  discussion  summarizes  die  foldings  of  the  panel: 

1 .  Immaturity  of  SAFOR  Technology 

All  of  die  panelists  emphasized  that  SAFOR  is  rapidly  changing  and  evolving — that 
it  is  not  a  mature  technology  ready  for  "type  classification"  and  fielding.  CCTT  SAFOR 
will  remain  a  dynamic  area  for  several  years  to  come,  and  ModSAF  itself  needs  continued 
development.  Even  if  designs  and  approaches  for  SAFOR  were  more  settled  and 
understood,  die  new  post-Cold  War  threat  environment,  which  is  equivalently  dynamic  and 
rapidly  evolving,  will  demand  quick  and  occasionally  urgent  representation  of  new 
opponents,  allies,  terrain,  and  situations  in  SAFOR.  These  representations  may  become 
available  from  other  programs  entirely  separate  from  SAFOR  and  DIS.  The  degree  to 
which  CCTT  and  CATT  SAFOR  developments  remain  flexible  and  capable  of  easily 
incorporating — without  major  re-engineering  or  re-design — useful  products  and  ideas  from 
all  these  rapidly  evolving  sources  will  substantially  impact  the  quality,  relevance,  and  utility 
of  their  products. 

2.  Coordination  with  Research  and  Development 

All  of  the  panelists  discussed  the  specific  need  to  coordinate  research  and 
development  products  with  those  produced  for  CATT  SAFOR.  They  raised  the  following 
points: 

(a)  CATT  SAFOR  development  will  help  focus  research  priorities,  frame  research 
questions,  and  provide  a  meaningful  baseline  with  which  to  compare  new 
research  results.  However,  CCTT  SAFOR  is  an  engineering  development 
program  that  needs  an  externally  provided  science  and  technology  base.  The 
flow  of  products  and  ideas  from  research  and  development  to  CATT,  as 
discussed  above,  is  important.  Also  important  is  the  flow  of  ideas  and 
products  in  the  opposite  direction,  from  CATT  to  research  and  development 
efforts.  These  efforts  will  need  access  to  genuine,  user-produced  SAFOR 
modules.  Employment  of  CATT  products  for  this  purpose  will  substantially 
improve  the  quality  and  relevance  of  products  from  research  and  development 
efforts,  and  it  will  improve  the  efficiency  with  which  they  are  produced. 
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(b)  It  is  unlikely  that  CCTT  and  CATT  modules  will  be  used  as  directly 
substitutable  "black-boxes"  by  researchers.  Even  if  standardized  interfaces  can 
be  designed,  constructed,  and  enforced  to  meet  SAFOR  needs  for  product 
exchange,  researchers  will  still  need  to  make  modifications  within  modules  to 
accommodate  their  objectives.  A  mixed  bag  of  modules  in  various  languages 
will  discourage  these  modifications  and  their  potential  for  promoting  reuse  and 
coordination  even  if  the  interface  specifications  are  well  defined.  These 
modifications  will  be  practicable  for  researchers  only  if  they  can  be 
accomplished  using  software  tools,  architectures,  and  approaches  with  which 
they  are  familiar. 

(c)  The  panelists  noted  specifically  that  die  planned  development  of  1200  Combat 
Instruction  Sets  (CIS)  will  be  "the  largest  representation  of  intelligent  human 
behavior  ever  undertaken"  and  a  major  step  forward  in  representing  military 
behavior.  No  other  program  will  have  the  resources  in  the  foreseeable  future 
needed  to  create  or  re-create  this  body  of  knowledge.  It  is  therefore  essential 
for  the  CIS  modules  to  be  easily  available  not  only  to  all  members  of  the 
research  and  development  community,  but  to  all  developers  concerned  with 
DIS  and  otherwise.  Few  of  these  developers  and  fewer  researchers  will  be 
able  to  find  the  resources  needed  to  adopt  CIS  modules  from  one  programming 
architecture  and  environment  to  another. 

(d)  Without  coordination  between  these  communities,  discrepancies  between  their 
products,  functionalities,  approaches,  and  designs  will  inevitably  arise,  testing 
and  calibration,  which  is  difficult  enough  in  the  SAFOR  environment,  will 
become  more  complicated,  and  products  from  the  technology  base  will  be 
harder  to  produce,  less  relevant,  and  more  difficult  to  incorporate.  If  this 
coordination  is  achieved,  shared  software  expertise  and  rapid  exchange  of 
products  and  ideas  will  increase  the  efficiency  with  which  all  lines  of  SAFOR 
development  proceed,  and  it  will  increase  the  quality  of  their  products. 

3 .  Breadth  of  the  SAFOR  Requirement 

Five  panelists  emphasized  that  the  issues  raised  by  CATT  SAFOR  development  are 
broader  than  requirements  for  CATT  alone — significant  as  that  program  is.  The 
community  of  SAFOR  users  is  larger  and  more  diverse  than  that  originally  contemplated 
and  it  continues  to  grow.  For  instance,  Lt.  General  Forster,  the  Deputy  Acquisition 
Executive  of  the  Army,  has  recently  directed  Army  acquisition  executives  to  use  simulation 
for  all  Army  acquisition  programs,  thereby  further  increasing  the  body  of  SAFOR 
developers  and  users.  To  be  accepted  in  these  communities,  CATT  SAFOR  must  provide 
validated  data  and  models,  operator  suitability,  a  ready  ability  to  test  and  calibrate  the 
system,  and  use  in  applications  beyond  training.  Success  for  CATT  SAFOR  development 
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may  be  measured  as  much  by  wide  user  acceptance  and  its  support  for  the  full  community 
of  SAFOR  users  as  by  its  support  for  development  within  the  CATT  family  of  systems. 

4.  Re-engineering  of  ModSAF 

Two  panelists  discussed  their  favorable  impressions  of  both  the  ModSAF 
architecture  and  its  re-engineering  for  CCTT.  They  suggested  that  the  CCTT  architecture  is 
a  commendable  improvement.  On  the  other  hand,  they  pointed  out  that  the  re-engineered 
architecture  is  itself  untested  and  unproved — certainly  less  so  than  ModSAF.  The  re¬ 
engineered  COT  SAFOR  architecture  should  be  as  subject  to  careful  scrutiny  as  any  other 
SAFOR  approach. 

5.  Quality  of  Software  Engineering 

Three  panelists  emphasized  that  it  is  the  programmer  more  than  the  language  that 
produces  well-engineered  software,  allowing  efficient  maintenance  and  reducing  life-cycle 
resource  requirements.  Most  specifically,  the  software  engineering  discipline  imposed  by 
an  Ada  programming  environment  can  be  also  be  enforced  by  programmers  using  the  C 
and/or  C++  environments  that  are  used  for  SAFOR  developments  elsewhere. 

6 .  Commercial  Tools 

Four  panelists  noted  that  the  accessibility  of  any  software  product  will  be  enhanced 
by  the  use  of  tools  that  are  available  at  reasonable  cost  and  that  operate  on  a  variety  of 
computing  platforms.  These  observations  arose  directly  from  the  proposed  used  of 
RTWorks  in  plans  for  CCTT  SAFOR,  but  they  generalize  to  the  use  of  any  tool  for 
software  development  or  operation. 

7.  National  Guard  Requirements 

One  panelist  discussed  the  emerging  and  increased  responsibilities  of  the  National 
Guard  in  readiness  and  direct  combat  preparedness.  These  responsibilities  suggest 
increased  needs  to  enhance  small  unit  performance  and  support  mission  rehearsal. 
Significant  steps  toward  meeting  these  needs  are  provided  by  the  editor  *  unctions  in 
ModSAF  and  the  production  of  modules  that  are  compatible  with  these  editors.  The 
National  Guard's  need  for  behavioral  detail  at  the  small  unit  level  should  not  be  lost  to  the 
demands  of  active  component  commanders  for  greater  levels  of  aggregation. 
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8.  C  and  C++  Programming  Environments 

Two  panelists  discussed  the  extent  of  resources  available  in  C  and  C++ 
programming  environments.  Mane  specifically  they  argued  that  C  and  C++  environments 
provide  all  the  basics  of  good  software  engineering  and  practice  such  as  systems,  tools, 
compiler  speed,  object  orientation,  efficient  code  generation,  concurrency  support, 
hierarchical  capabilities,  abstraction,  encapsulation,  modularity,  and  even  strong  typing. 
They  also  argued  that  these  resources  are  more  readily  available  from  C  and  C++  than  from 
Ada  environments,  due  in  significant  measure  to  the  greater  number  of  C  programmers, 
systems,  and  tools,  and  lower  costs  in  terms  of  time,  budget,  and  computer  resources. 

C.  RECOMMENDATIONS 

1.  All  panel  members  recommended  that  CCTT/CATT  SAFOR  should  be 
developed  to  facilitate  and  maximize  interchange  between  its  products  and  ideas 
and  those  of  all  other  communities,  but  especially  those  of  the  R&D 
community.  Development  of  parallel  but  computationally  different  SAFOR 
systems  should  not  be  pursued  nor  supported. 

2.  All  panel  members  concluded  that  CCTT  SAFOR  should  not  be  developed  in 
Ada.  It  should  be  developed  in  C  or  in  C++.  The  costs — in  terms  of 
resources  and  time — of  this  recommendation  were  taken  into  consideration. 
All  members  of  the  panel  concluded  that  benefits  arising  from  this  decision 
outweigh  its  cost 

3.  Four  panel  members  emphasized  that  products  from  the  CATT  SAFOR 
developments  should  be  made  as  accessible  as  possible  and  that  the  use  of 
elaborate  commercial  shells  and  tools  should  be  avoided. 

4.  Four  panel  members  specifically  recommended  the  use  of  the  C  Language 
Integrated  Production  System  (CLIPS)  in  place  of  RTWorks.  One  member 
further  recommended  the  use  of  CLIPS  Object-Oriented  Language  (COOL). 

5.  Two  panel  members  specifically  recommended  the  use  of  object-oriented 
analysis  and  design  tools  to  provide  traceability  and  design  documentation. 

6.  One  panel  member  recommended  appointment  of  an  advisory  panel  with 
representatives  from  all  concerned  SAFOR  communities  to  provide  continued 
assistance  to  PM  CATT.  More  generally,  another  member  recommended  that 
PM  CATT  continue  to  solicit  review  and  feedback  from  the  research  and 
development  community. 

7.  Three  panel  members  commended  the  use  of  people  in  addition  to  careful 
documentation  and  good  software  engineering  practice  to  effect  coordination 


between  CCTT  SAFOR  production  and  other  communities,  and  they 
recommended  that  this  practice  be  continued. 

8.  One  panel  member  commended  the  emphasis  on  human  computer  interaction  in 
CCTT  SAFOR  development  and  recommended  that  it  receive  continued 
emphasis. 

9.  Three  panel  members  commended  the  emphases  on  concurrent  engineering  and 
cyclic  simulation  feedback  for  CIS  development  and  recommended  that  these 
approaches  continue  to  receive  emphasis. 

10.  Five  panel  members  recommended  a  strong  insistence  on  good  software 
engineering  practices.  PM  CATT  should  not  rely  on  the  enforcement 
capabilities  inherent  in  a  programming  language.  Module  interface  design, 
documentation,  data  abstraction  (with  data  separated  from  code),  and 
standardized  implementation  via  MIL-STD-2167A  should  all  receive  continued 
emphasis. 

11.  Three  panel  members  recommended  that  flexibility,  accessibility,  and 
adaptability  be  weighed  more  than  life-cycle  maintainability  in  the  development 
of  CATT  SAFOR  products. 

12.  One  panel  member  recommended  that  priority  in  SAFOR  development  be  given 
to  entity-level  behavior  and  small  unit  performance. 

13.  Two  panel  members  specifically  commended  the  Integrated  Development 
Team's  ModSAF  re-engineering  effort,  and  they  recommended  that  further 
development  build  on  this  effort  where  possible. 

14.  One  panel  member  recommended  that,  if  development  continues  in  Ada,  at 
least  one  additional  round  of  SAFOR  enhancements  should  be  undertaken 
before  the  system  is  fielded. 

15.  Two  panel  members  recommended  that  the  CATT  development  community 
should  take  a  more  active  role  in  funding  research — specifically  it  should  pick 
up  what  ARPA  may  leave  unaddressed  or  unfinished. 


D.  CONCLUSIONS 

In  brief,  the  panel  concluded  that  the  widest  possible  community  should  develop 
and  share  ownership  in  a  CCTT  SAFOR  product  that  is  produced  using  the  best  available 
notions  for  software  engineering.  More  specifically: 

•  The  same  SAFOR  products  can  and  should  be  used  to  support  both  the 
research  and  development  and  the  user  community; 
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Two  computationally  separate  SAFOR  lines  of  development,  one  based  on  an 
Ada  environment  and  one  based  on  a  C  environment,  would  inevitably  develop 
discrepancies,  become  insufficiently  coordinated,  and  should  not  be  pursued; 

The  research  and  development  community  and  other  interested  communities  are 
unlikely  to  have  either  the  resources  or  inclination  to  migrate  to  an  Ada 
programming  environment; 

Products  from  CATT  SAFOR  development  should  be  made  as  accessible  and 
adaptable  as  possible — higher  priority  should  be  given  to  accessibility  and 
adaptability  than  to  life-cycle  maintainability; 

CATT  SAFOR  development  should  be  pursued  using  a  C  and/or  C++ 
programming  environment. 


COMMENTS  BY  PHILIP  ANTON 


1.  SAFOR  PRODUCTS 

SAFOR  is  an  immature  field  with  rapidly  evolving  techniques,  components,  and 
requirements.  As  such,  it  is  very  difficult  but  not  impossible  to  construct  SAFOR  products 
that  meet  some  of  the  common  needs  of  the  R&D  and  User  communities.  Such  products 
must,  however,  possess  several  properties,  including  flexibility,  rigorously  defined 
interfaces,  and  design  with  "shared"  requirements  in  mind. 

As  components  become  stabilized  and  approaches  become  common,  those 
components  can  be  reused  by  the  SAFOR  community  at  large.  Note,  however,  that 
standardization  does  not  imply  restricted  access  to  components.  The  R&D  community  has 
the  task  of  continually  investigating  SAFOR  architectures  as  a  whole  and  will  continue  to 
need  die  flexibility  to  investigate  modifications  or  alternative  approaches  of  components. 
DIS  PDU  standards  may  be  somewhat  stable  in  their  description  of  entity  movement,  but 
solutions  to  the  problems  of  scalability  and  fault  tolerance  may  require  modifications  not  of 
the  network  itself  but  of  the  entire  approach  to  SAFOR  architectures  to  include  entity  and 
behavioral  representations,  PDU  generation  approaches,  and  database  structures.  The 
R&D  community  must  have  the  ability  to  test  out  alternative  solutions  to  such  problems  if 
the  state  of  the  art  is  to  be  advanced. 

If  we  are  to  reuse  components  of  the  architecture,  then  the  interfaces  between  the 
components  must  be  rigorously  defined  to  meet  common  requirements. 

Common  products  that  should  be  sharable  today  include: 

•  A  generic  SAFOR  architectural  shell,  including 

-  DIS  PDU  interfaces 

-  simulation  support,  including  stochastic  and  deterministic  options 

-  dead  reckoning  algorithms 

-  coordinate  system  transformation  algorithms 

-  libraries  of  behavioral  processing  engines,  including  task  frames,  rule- 

based  inference  engines,  etc. 
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•  Knowledge  bases  of  entity  behaviors  (e.g..  Combat  Instruction  Sets,  or  CIS) 

•  Databases  of  vehicular  dynamic  parameters. 

Components  that  should  NOT  be  farced  into  a  baseline  SAFOR  include: 

•  Froprietary/COTS  tools 

—  cost  barriers  to  use 

—  inaccessibility  for  study  and  extension  by  the  research  community 

—  dependence  on  the  supplying  company  for  all  future  developments. 

Government  or  research  developed  software  may  cost  more  initially  to  develop,  but 
in  the  long  run  it  can  reduce  costs  and  increase  longevity  if  proper  care  to  support  reuse  and 
common  design  is  employed. 

Note  that  the  knowledge  bases  and  databases  should  be  constructed  in  an 
architecture-independent  fashion  whenever  possible.  Knowledge  bases  implemented  as 
data  rather  than  in  source  code  languages  (e.g.,  Ada  or  C  code)  allow  for  continued 
development  of  die  processors  of  the  knowledge  data. 

The  degree  to  which  the  same  SAFOR  products  can  support  different  communities 
is  a  function  of 

•  the  degree  to  which  common  requirements  can  be  found 

•  the  stability  of  the  design  and  implementation  of  components  which  can  be 

reflected  either  in  the  formal  establishment  or  the  SAFOR  community. 

Even  within  a  single  community,  there  will  be  a  core  of  needs  based  on  the  types  of 
processing  that  community  does,  but  studies  will  often  need  to  be  performed  beyond  the 
current  capabilities  of  the  community's  systems.  Most  people  need  a  module  that  handles 
the  standard  DIS  PDUs,  but  no  one  yet  agrees  on  the  approaches  that  should  be  used  in 
behavioral  representation.  The  OSA  DISC4  ASRMO  briefing  distributed  during  the  panel 
emphasized  this  stability  requirement  in  the  reuse  of  software. 

Standards,  of  course,  are  problematic  in  and  of  themselves.  Design-by-committee  is 
known  to  result  in  standards  that  at  best  meet  some  of  the  requirements  across  the 
communities  and  at  worst  do  not  meet  anyone's  requirements  due  to  extensive 
compromise.  The  research  community  by  its  nature  needs  the  flexibility  to  continue  to 
study  standardized  components  for  improvement 

Functional  interfaces  to  allow  experimentation,  replacement  and  remixing  of 
modules  hold  the  greatest  immediate  promise  in  establishing  specifications  that  can  be 
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reused.  Care  must  be  taken,  however,  to  design  these  interfaces  in  a  flexible  and  open 
architecture  to  maximize  the  ability  to  replace  and  upgrade  modules  as  time  goes  on  while 
providing  a  common  environment 

There  are  a  number  of  reasons  why  it  is  imperative  today  to  coordinate  SAFOR 
development  in  the  R&D  and  User  communities.  First  dwindling  DoD  funding  implies 
that  custom  software  development  for  each  developed  system  can  no  longer  continue. 
Reduced  funding  also  implies  that  each  system  development  project  cannot  afford  its  own 
Science  and  Technology  (S&T)  research  programs  to  support  its  unique  set  of 
requirements.  Reduced  funding  also  means  that  less  research  dollars  will  be  available  and 
more  research  will  have  to  be  directed  to  meet  the  immediate  needs  of  die  user  community. 
Thus,  the  R&D  and  User  communities  must  establish  ways  to  work  together  to  meet 
common  requirements  in  addition  to  meeting  their  own  unique  requirements.  This  will 
require  coordinated  efforts  and  discussions  on  technological  approaches  to  problems  as 
well  as  the  establishment  of  methods  to  support  the  direct  application  of  research  results 
into  development  systems  as  well  as  the  availability  and  use  of  validated  user  systems  in 
research  programs.  Not  only  will  die  feedback  of  systems  from  the  user  community  to  the 
R&D  community  save  development  money  of  common  modules,  but  research  in  the  user’s 
environment  will  focus  researchers  on  user  problems  rather  than  abstract  technological 
problems. 

There  is  an  unexploited  opportunity  in  the  SAFOR  community  to  reuse  not  only 
SAFOR  software  but  the  architectures,  specifications,  and  functional  descriptions  (e.g., 
component  techniques,  algorithms).  If  common  requirements  can  be  found  between  R&D 
and  development  programs,  then  the  effort  of  the  receiver  of  products  and  software  should 
concentrate  their  effort  not  on  re-engineering  the  received  software  but  cm  producing  the 
2167A  documentation  of  the  existing  software.  For  example,  ARPA  and  CCTT  have 
invested  significant  funds  to  develop  ModSAF.  Components  that  met  the  CCTT 
requirements  (e.g.,  PDU  handler)  could  have  been  used  directly  by  reverse  engineering 
appropriate  IDS,  IDD,  and  SRS  documents  to  describe  this  module.  These  specifications 
and  functional  descriptions  would  then  be  available  for  other  users  of  ModSAF,  resulting 
in  significant  reuse  and  cost  savings.  If  one  program  upgrades  the  PDU  handler  and 
associated  documentation  to  the  next  version  of  the  DIS  standards,  then  other  users 
(including  the  R&D  community)  could  immediately  upgrade  to  the  new  standard  with  little 
or  no  effort  If,  however,  the  PDU  handler  is  re-engineered  into  a  different  language,  then 
other  users  of  ModSAF  will  not  be  able  to  use  it  Having  a  mixed  bag  of  modules  in 
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various  languages  will  not  promote  reuse  of  the  modules  even  if  the  interface  specifications 
are  well  defined. 

If  a  developer  needs  to  extend  a  module's  capability  to  meet  a  specific  program 
requirement,  then  that  module  could  be  customized  to  meet  these  new  capabilities.  The 
issue  here  is  whether  these  extensions  meet  the  needs  of  the  broad  SAFOR  community  or 
just  the  present  program  under  development  If  consensus  is  reached  in  the  community  at 
large  that  the  extensions  are  useful  and  should  be  incorporated  in  the  baseline  SAFOR,  the 
module  could  readily  be  incorporated  in  everyone's  SAFOR  easily  if  the  same 
implementation  languages  is  used.  If,  however,  the  extensions  are  not  needed  or  agreed 
upon  by  the  community,  then  the  module  should  not  be  forced  upon  the  community.  For 
example,  if  CCTT  SAFOR  is  developed  in  Ada  or  is  a  complete  re-engineering  of  ModS AF 
(as  is  currently  planned)  and  the  extensions  that  the  IDT  have  included  in  the  SAFOR 
architecture  do  not  meet  a  consensus  requirement  by  die  community  (e.g.,  if  the  SAF  Entity 
Object  Database  -  SEOD  -  extensions  of  die  Persistent  Object  Protocol  -  PCX’  -  are  not  what 
the  SAFOR  community  at  large  needs),  then  providing  CCTT  SAFOR  back  to  the  R&D 
and  user  communities  will  "force"  these  non-consensus  designs  on  the  community  or  limit 
the  reusability  of  CCTT  as  a  baseline.  Only  if  CCTT  is  developed  in  die  common  language 
of  the  SAFOR  community  and  the  extensions  provided  by  individuals  are  discardable  or 
usable  by  virtue  of  well-defined  interfaces  can  the  reuse  of  SAFOR  products  provide 
valuable  growth  of  a  baseline  SAFOR  environment 

Note  that  the  CCTT  design  presented  at  the  workshop  is  "not"  a  mere  re¬ 
engineering  and  development  of  existing  SAFOR  ideas  and  research  results.  The  CCTT 
SAFOR  design  itself  is  a  new,  unproven  architecture  and  thus  constitutes  a  research 
development  effort  Who  is  to  say  that  die  architecture  is  sufficient  to  meet  the  stated  goals 
of  CCTT  and  latter  CATT?  If  ModSAF  was  insufficient,  then  a  re-engineering  of  ModS  AF 
(with  small  changes  and  the  inclusion  of  a  rule-based  shell)  may  be  insufficient  also.  But 
even  then,  ModSAF  has  yet  to  be  delivered  and  demonstrated  in  a  real,  validated  exercise. 

2.  SOFTWARE  APPROACHES 

In  order  to  satisfy  both  the  R&D  and  user  communities,  CCTT  SAFOR  should  use 
a  computer  language  that  is  efficient,  standardized,  in  common  use  in  both  communities, 
allows  good  software  engineering  practices,  and  has  compilers  that  are  fast,  readily 
available,  and  low  cost  The  obvious  candidates  are  Ada,  C,  and  C++. 


Ada  meets  most  of  the  requirements  but  its  compilers  are  slow,  expensive,  and  not 
commonly  used  in  the  R&D  community.  A  good  Ada  compiler  can  provide  reasonably 
efficient  code  and  provides  tight  error  checking  in  support  of  software  development,  but  the 
lack  of  Ada  availability  in  the  R&D  community  would  prevent  die  use  of  CCTT  SAFOR  as 
a  research  baseline  for  SAFOR  studies. 

C  and  C++  are  very  efficient,  standardized  languages  used  extensively  in  both 
communities.  GNU  compilers  for  C  and  C++  (published  by  the  Free  Software 
Foundation)  are  free,  readily  available  for  common  hardware  platforms,  and  among  the 
highest  quality  available,  often  surpassing  the  compilers  delivered  by  hardware  vendors. 
These  compilers  are  heavily  used  by  the  R&D  community  as  well  as  commercial  software 
developers.  While  C  (and  to  a  lesser  extent  C++)  do  not  provide  as  much  software 
engineering  support,  the  object-oriented  analysis  (OOA)  and  design  (OOD)  approaches 
already  adopted  by  the  CCTT  IDT  will  provide  significant  software  engineering  support 
and  traceability  from  specifications  to  code.  In  addition,  the  quality  of  the  code  developed 
ultimately  depends  on  the  quality  of  the  programmer,  not  on  the  language  chosen.  Good 
programmers  can  produce  well-designed,  quality  code  in  any  language,  and  poor 
programmers  can  produce  poor  code  in  any  language  (including  Ada). 

Judicious  use  of  C++'s  object-oriented  features  could  provide  flexible  object 
implementations  while  minimizing  inefficiencies  inherent  in  object-oriented  languages,  but 
care  must  be  taken.  The  ModSAF  team  made  a  deliberate  (and  allegedly  informed)  design 
decision  to  provide  a  custom  object-based  (not  object-oriented)  implementation  of  entity 
components  for  efficiency  reasons.  Creation  of  complex  inheritance  structures  of  objects 
combined  with  uninformed  use  of  the  language  can  result  in  unexpected  inefficiencies. 
Nevertheless,  C++  does  provide  fundamental  object-oriented  features  that  can  facilitate 
flexible  design  in  an  efficient  manna:. 

Note  that  question  2  poses  that  the  R&D  needs  of  flexibility  ami  ease-of-use  are 
pitted  against  the  user  community  needs  of  configuration  control,  life-cycle  maintenance, 
and  reliability  issues.  In  the  immature  field  of  SAFOR,  however,  things  are  not  this  clear 
cut  CCTT  will  need  to  continue  to  fold  in  new  research  results  and  approaches  (e.g., 
C2  Simulation  Interface  Language — CCSIL,  results  in  Behavioral  Representation  and 
Dynamic  Terrain)  from  the  research  community  as  they  are  proven  and  become  available. 
Thus,  CCTT  will  not  have  a  traditional  life  cycle  of  static  requirements,  implementation, 
and  slow  software  maintenance.  CCTT  itself  must  remain  flexible,  open,  and  easy  to  use 
in  order  to  take  advantage  of  breakthroughs  in  SAFOR  technology  and  remain  useful. 
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Thus,  overemphasis  on  traditional  life-cycle  maintenance  (for  which  Ada  claims  excellence) 
at  the  expense  of  flexibility  does  not  match  die  CCTT  (and  CATT)  role  in  Army  training. 
CCTT  and  CATT  has  (or  should  have)  the  explicit  requirement  of  including  the  needs  of 
the  R&D  community  since  it  is  a  critical  part  of  the  'life-cycle"  of  die  CATT  program. 

As  for  the  use  of  software  shells,  I  would  like  to  argue  strongly  against  the  use  of 
commercial  shells.  The  use  of  shells  such  as  RTWorks  may  provide  extensive  support 
facilities  for  CCTT  development,  but  the  inclusion  of  such  commercial  products  will  greatly 
limit  who  will  be  able  to  use  die  CCTT  SAFOR  environment,  including  the  very  research 
organizations  to  whom  CATT  will  turn  for  results  to  meet  the  CATT  goals.  Also,  the 
SAFOR  community  is  still  struggling  with  what  types  of  behavioral  representations  are 
appropriate  for  what  types  and  levels  of  battlefield  entities.  A  rule-based  system  may  be 
useful  for  higher-level  aggregate  entities,  but  there  has  been  no  research  on  this  point  to 
date  and  certainly  no  data  to  demonstrate  that  the  syntax  provided  in  RTWorks  is  necessary 
and  sufficient  to  express  the  behavioral  rules  for  Army  units. 

There  are  many  well-engineered  inference  engine  shells.  CLIPS  is  a  GOTS, 
C-based,  real-time  inference  engine  shell  that  supports  rule-based,  object-oriented,  and 
procedural  paradigms  and  comes  with  X-based  development  tools.  It  is  highly 
recommended  in  the  research  community  and  commonly  used.  CLIPS  is  available  from  the 
Software  Technology  Branch  of  the  NASA  Johnson  Space  Center,  is  free  to  government 
agencies  and  contractors,  and  relatively  inexpensive  for  others  ($150-300  range). 

If  CCTT  must  use  RTWorks,  then  a  requirement  should  be  formally  placed  on  the 
IDT  to  specify  the  interface  between  RTWorks  and  the  rest  of  CCTT  SAFOR  to  allow  easy 
removal  or  replacement  of  the  RTWorks  inference  engine  for  research  studies  and  other 
SAFOR  developments.  Knowledge  bases  (i.e.,  CIS  data)  should  employ  the  rule-based 
system  in  such  as  way  to  allow  the  rule-based  engine  to  be  functionally  replaceable  with  a 
different  behavioral  system  (e.g.,  a  different  knowledge-based  system,  SOAR,  planner, 
probabilistic  reasoning,  etc.). 

Thus,  I  recommend  that  CCTT  SAFOR  be  implemented  in  C  or  C++  (with 
preference  to  C++).  Object-oriented  analysis  and  design  tools  should  continue  to  be 
employed  for  CCTT;  these  tools  provide  the  critical  requirements  traceability  and  design 
documentation  for  CCTT  development  under  2 167 A  while  providing  important 
documentation  for  other  users  of  CCTT  SAFOR  code. 
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3.  OTHER  AVAILABLE  PRODUCTS 

ModSAF  ideas  have  already  been  re-engineered  into  the  CCTT  SAF,  and  I  have  no 
direct  experience  with  1ST  CGF.  I  would  have  recommended  a  more  direct  use  of 
ModSAF  code  with  an  associated  effort  to  reverse  engineer  just  the  2167A  documents  for 
the  ModSAF  architecture.  Unfortunately,  the  re-engineering  decision  has  already  been 
made. 

As  for  other  tools  that  could  be  used  to  aid  the  development  of  CCTT  SAFOR, 
I  would  strongly  recommend  the  use  of  the  GOTS  CLIPS  inference  system  rather  than 
RTWorks.  If  CLIPS  were  to  be  used,  I  would  recommend  reverse  engineering  of  the 
2167A  documents  for  CLIPS  (if  not  already  available)  rather  than  a  complete  re¬ 
engineering  effort  This  would  allow  other  users  to  have  easy  access  to  the  inference 
engine  of  CCTT  at  a  negligible  cost,  save  re-engineering  costs  for  CCTT,  and  allow  CCTT 
to  give  back  to  the  R&D  community  the  specifications  for  CLIPS  so  that  other  programs 
that  need  such  an  engine  would  be  able  to  re-use  these  specifications. 

4.  COMMUNITY  CONSENSUS  STEPS 

Consideration  of  R&D  community  requirements  when  making  programmatic  and 
design  decisions  is  crucial  to  supporting  CCTT  and  other  CATT  programs.  If  CATT  is  to 
succeed,  then  it  must  be  flexible  enough  to  include  research  results  in  SAFOR.  Also,  given 
the  limited  R&D  funds,  CATT  must  support  the  R&D  community  by  promoting  a  SAFOR 
environment  to  focus  research  on  user  problems  and  provide  a  validated  environment  in 
which  to  perform  the  research. 

To  promote  consensus,  PM-CATT  should  convene  an  advisory  panel  to  include 
representatives  from  both  the  R&D  and  user  communities  (possibly  including  joint  service 
representatives)  to  make  continued  recommendations  on  design  decisions.  Difficult 
questions  need  to  be  addressed  and  recommendations  made  as  a  result  of  the  IDT  decisions 
to  date: 

(i)  If  CATT  is  developed  in  C  or  C++,  how  can  the  ongoing  ModSAF 
development  be  integrated  with  the  CATT  delivery  system?  What  parts  of  the  CATT 
system  can  be  used  by  a  generic  SAFOR  and  thus  included  in  a  re-merged  ModSAF-CCTT 
system? 

(ii)  Review  and  make  recommendations  on  the  interface  specifications  between  the 
modules  in  the  CATT  architecture.  Should  an  effort  be  started  to  define  generic  open- 
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architecture  interface  standards  to  facilitate  SAFOR  "Plug  and  play"  of  components?  Can 
die  WARSIM  2000  architecture  be  used  for  this?  What  progress  has  WARSEM  made  and 
can  the  CATT  interfaces  be  specified  within  the  WARSIM  architecture  to  facilitate 
coordination  with  WARSIM  in  the  future? 

(hi)  Review  and  make  recommendations  on  the  behavioral  representation  design 
decisions  in  CATT,  to  include: 

•  die  interface  between  RTWorks  and  the  rest  of  die  system, 

•  die  design  decisions  regarding  the  implementation  of  the  CIS  database. 

For  example,  will  QSs  be  implemented  as  source  code  (as  in  the  ModSAF  tasks) 
or  can  they  be  implemented  as  data  (e.g.,  ASCI  text)  in  a  certain  syntax  to  be  operated  on 
by  processing  engine(s)  in  the  architecture,  independent  of  the  engine? 

(iv)  How  can  the  current  ARPA  research  efforts  (e.g.,  CCSIL)  be  designed  and 
developed  to  facilitate  direct  use  in  CATT  programs  as  needed  without  a  re-engineering 
effort?  Who  should  fund  and  develop  EDS  and  SRS  for  such  software  modules? 

(v)  If  continued  coordination  is  necessary  between  die  R&D  and  user  communities 
for  SAFOR,  what  arrangements  and  structures  can  be  established  to  facilitate  this 
coordination?  Should  ARPA  be  the  keeper  of  a  baseline  SAFOR  environment?  If  not,  then 
who?  DMSO?  The  Army? 

(vi)  Given  the  shrinking  DoD  funds  for  developing  new  systems,  what  advice  can 
be  given  to  future  Program  Managers  on  how  to  control  contractor's  natural  tendency  to 
want  to  build  custom  systems  rather  than  reuse  existing  software  whenever  possible? 

(vii)  If  the  Army  becomes  the  repository  of  the  baseline  SAFOR,  will  other 
services  be  less  inclined  to  reuse  it  than  if  the  software  came  from  a  service-independent 
source  (e.g.,  ARPA  or  DMSO)?  How  can  such  "rice  bowl"  issues  be  reduced  in  a  joint 
environment? 

(viii)  CCTT  has  demonstrated  that  personal  interaction  between  software 
developers  (e.g.,  LADS)  and  the  software  re-users  (e.g.,  CCTT  IDT)  was  very  valuable  in 
transferring  an  understanding  of  ModSAF.  Unfortunately,  this  kind  of  personal  interaction 
is  not  possible  in  all  cases  given  availability  and  cost  considerations.  What  types  of 
documentation  would  facilitate  software,  architecture,  and  algorithm  transfer  between 
communities  given  the  need  to  re-use  designs?  Should  researchers  (or  someone  following 
up  on  the  research's  work)  spend  the  time  to  document  the  code  using  2167A  require- 
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meats?  What  other  techniques  could  be  employed?  Note  here  that  the  emphasis  should  not 
be  to  manage  by  consensus  or  committee  but  to  bring  to  light  issues  important  to 
coordinated  development  and  re-use  of  SAFOR  products  and  to  make  recommendations  to 
PM-CATT  on  how  to  meet  the  immediate  CATT  needs  while  considering  the  requirements 
of  the  SAFOR  community  as  a  whole. 


5 .  SPECIFIC  STEPS  TO  IMPLEMENT  CCTT  SAFOR 

In  summary,  I  recommend: 

•  Implementation  of  CCTT  in  C++  (or  C). 

•  Continued  use  of  OOA  and  OOD  tools. 

•  Emphasize  good  software  engineering  practices  rather  than  reliance  on  a 
software  language's  inherent  enforcement  of  certain  practices  (e.g..  Software 
Engineering  Institute  ratings). 

•  Continue  special  attention  to  the  UCI,  which  is  critical  if  the  system  is  to  be 
successful. 

•  Continued  emphases  on  concurrent  engineering  and  cyclic  simulation  feedback 
for  CIS  development 

•  Consider  the  use  of  nonproprietary  software  in  place  of  RTWorks  (e.g., 
CUPS). 

•  Consider  die  CIS  implementation  format  and  the  inpact  of  this  design  decision 
<mi  reusability  of  the  CIS  data  (i.e.,  implement  each  CIS  as  data  versus 
software  code).  Can  a  generic  description  of  CIS  components  implemented  as 
rules  be  reached  independent  of  the  syntax  of  the  CCTT  inference  engine? 

•  Pay  special  attention  to  explicit  and  rigorous  interface  design,  documentation, 
and  implementation  for  the  CCTT  architecture  modules  to  facilitate  re-use  and 
individual  replacement  for  research  and  development  in  other  SAFOR  systems. 

•  Negotiate  a  plan  for  integrating  CCTT  with  ModSAF,  replacing  parts  of 
ModS  AF  with  parts  of  CCTT,  or  some  other  approach  to  provide  some  kind  of 
common  SAFOR  baseline  environment  that  other  SAFOR  programs  can  build 


•  Seek  the  advice  of  both  the  R&D  and  user  communities  in  addressing  the 
questions  outlined  above  in  section  4. 

The  major  design  concerns  identified  are: 

•  The  impact  of  the  use  of  the  SEOD  on  scalability  in  CATT  SAFOR  (an  open 
research  issue). 
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•  The  inclusion  of  proprietary  software  in  the  CCTT  architecture  and  the  degree 
to  which  this  software  is  integral  to  the  whole  CCTT  system. 

Lessons  Learned: 

•  Concurrent  validation  with  knowledge  engineering  efforts  should  be  promoted. 
Similarly,  iterative  simulation  feedback  should  be  employed  in  addition  to 
extraction  of  textual  description  from  Subject  Matter  Experts  and  doctrinal 
documents  (ref.  CIS  and  WISSARD). 

•  Greater  care  must  be  paid  to  explicitly  issuing  related  requirements  during 
initial  program  studies  if  any  other  community's  needs  are  a  factor  in 
programmatic  decisions.  For  example,  the  requirement  of  flexibility  in  rapidly 
incorporating  research  results  in  CATT  programs  as  well  as  the  need  to  offer 
CCTT  SAFOR  to  other  programs  for  research  and  development  purposes 
needed  to  be  included  as  explicit  criteria  in  the  CCTT  IDT  SAFOR  Trade 
Study.  As  the  R&D  and  user  communities  need  to  rely  on  each  other  and 
leverage  each  other's  work,  this  reliance  needs  to  formally  be  recognized  in 
program  requirements.  Note  that  developers  and  managers  have  a  natural 
tendency  to  make  design  decisions  to  maximize  the  perceived  risk  to  the 
explicit  requirements  even  if  these  decisions  are  not  the  best  compromise  for 
the  explicit  and  implicit  requirements  as  a  whole. 

•  The  use  of  independent  panels  such  as  ours  (hopefully)  helps  to  bring  flesh 
perspectives  to  bear  on  programmatic  issues  as  well  as  support  cross  fertilizing 
of  information  between  communities  regarding  important  programs  that  will 
impact  them. 

•  "Optimize  for  change,  since  change  will  surely  come."  (Gen.  Paul  Gorman) 
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COMMENTS  BY  PETER  BROOKS 


SUMMARY 

The  Program  Manager,  CATT,  asked  the  Panel  to  consider  CCTT  SAFOR  from 
two  perspectives.  First,  is  the  current  approach  for  CCTT  SAFOR  well-suited  to  the  needs 
of  other  SAFOR  development  and  user  communities?  Second,  what  products  and 
strategies  would  enhance  the  development  of  CCTT  SAFOR? 

Several  key  observations  emerged  during  the  briefings  and  subsequent  discussion: 

•  It  is  important  for  CCTT  to  demonstrate  that  a  common  development 
environment  exists  for  DIS  applications. 

•  SAFOR  technology  will  remain  an  active  research  and  development  area  for 
several  years. 

•  CCTT  is  a  6.4  program,  and  thus  needs  an  external  science  and  technology 
base. 

•  CCTT  SAFORs  will  be  successful  only  if  it  attains  wide  user  acceptance.  Key 
factors  include  validated  data  and  models,  operator  suitability,  a  ready  ability  to 
test  and  calibrate  the  SAFOR  system,  and  use  in  applications  beyond  training 
(e.g.,  acquisition  support). 

Based  on  the  discussions,  two  potential  recommendations  are: 

•  PM  CATT  should  establish  programmatic  ties  and  maintain  commonality  with 
die  ARPA  SAFOR  research  efforts. 

•  PM  CATT  should  ensure  that  the  CCTT  SAFOR  is  readily  accessible  to  broad 
user  and  developer  communities. 

There  are  several  elements  of  the  current  development  strategy  worth  noting.  These 
include: 

•  the  high  degree  of  user  and  proponent  involvement 

•  the  structure  of  and  process  for  developing  the  Combat  Instruction  Sets. 

•  the  relocation  of  personnel  among  the  IDT  and  Loral  sites. 

•  the  study  of  how  ModSAF  might  be  re-engineered. 

•  the  efforts  to  maintain  traceability  from  requirements  through  development. 
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The  above  observations  argue  for  using  software  tools,  techniques,  and  languages 
favored  by  die  R&D  community. 

THE  BENEFITS  OF  A  COMMON  DEVELOPMENT  ENVIRONMENT 

CtlT,  as  the  first  major  program  in  Distributed  Interactive  Simulation  (DIS)  since 
the  conclusion  of  SIMNET,  represents  a  key  test  case  for  the  development  and  use  of  DIS. 
The  premise  of  DIS  today  is  that  each  development  program  adds  to  the  whole,  that  new 
capabilities  are  easily  added  into  existing  systems,  and  that  DIS  is  generally  useful  for 
applications  beyond  training. 

CCTT  must  thus  demonstrate  that  major  software  components  and  development 
techniques  can  be  re-used.  The  benefits  are  clear  in  the  context  of  the  other  CATT 
programs,  and  one  would  expect  a  high  level  of  commonality  from  the  start  But  the 
development  also  should  contribute  to  a  Joint  DIS-based  training  system.  In  this  vein, 
there  seems  to  be  too  little  consideration  to  how  CCTT  will  operate  chi  a  wide  area  network 
(CCTT  has  high  bandwidth  requirements;  local  net  is  FDDI),  though  this  is  identified  as  a 
preplanned  product  improvement 

For  user  communities  beyond  training  (e.g.,  acquisition),  there  will  be  the  need  to 
add  new  capabilities  or  modules  to  CCTT  SAFOR,  and  to  exercise  SAFOR  in  their  own 
laboratories.  These  users  must  be  able  to  replicate  and  easily  work  in  the  development 
environment  established  for  CCTT  SAFOR. 

The  "entry  cost"  to  CCTT  SAFOR  therefore  must  remain  low,  through  the  use  of 
commonly  used  hardware  and  software  (e.g.,  C  or  C++),  and  the  lack  of  proprietary  or 
expensive  components  (c.g.,  will  RTWorks  make  CCTT  SAFOR  unaffordable  to  most 
researchers?). 

SAFOR  TECHNOLOGY  IS  AN  ACTIVE  R&D  AREA 

The  ARPA  research  in  SAFOR  will  continue  for  several  more  years,  at  a  funding 
level  several  times  that  of  CCTT  SAFOR.  CCTT  should  provide  for  the  easy  incorporation 
of  new  SAFOR  technologies  by  ARPA. 

SAFOR  will  evolve  for  other  reasons  as  well.  New  users  will  demand  or  develop 
added  capabilities  (cf.  Gen.  Forster  directive  to  Army  Acquisition  Executives  to  use 
simulation  for  all  systems  acquisition  programs).  In  other  cases,  new  SAFOR  capabilities 
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will  be  added  due  to  pressing  needs  (e.g.,  SAFOR  vehicles  being  given  a  newly  developed 
vehicle  mounted  countermine  system). 

These  points  argue  for  having  the  CCTT  SAFOR  system  and  the  baseline  research 
SAFOR  system  be  largely  interchangeable. 

CCTT  REQUIRES  AN  EXTERNAL  SCIENCE  AND  TECHNOLOGY  BASE 

Because  CCTT  uses  6.4  funding,  it  relies  on  external  programs  for  research  and 
development  work.  Many  organizations  will  contribute  to  improving  SAFOR  (e.g.,  terrain 
reasoning,  command  and  control  algorithms,  new  munitions  effects,  programs  for  the 
individual  soldier,  etc.).  To  incorporate  these  contributions  may  require  more  than  well- 
defined  interfaces  that  treat  SAFOR  as  a  black  box.  Such  general  interfaces  may  be  too 
hard  too  construct,  anyway.  Instead,  it  may  be  necessary  for  the  researchers  to  work  with 
the  code  directly. 

If  CCTT  is  relying  on  ARPA  as  the  main  source  of  research  directed  at  SAFOR, 
then  such  advances  should  be  incorporated  into  CCTT  without  extensive  re-engineering  of 
each  added  capability.  A  programmatic  connection  between  CCTT  and  ARPA  may  help 
here. 

CCTT  SAFORS  SUCCESS  BASED  ON  WIDE  USER  ACCEPTANCE 

CCTT  SAFOR  will  be  viewed  as  the  official  SAFOR,  and  therefore  the  system  of 
choice,  as  it  will  contain  Army-validated  behaviors  and  data.  To  ensure  its  utility  to  user 
communities  beyond  training  will  require  better  performance  in  the  user-computer  interface 
(UCI)  and  in  SAFOR  testing  than  exist  today. 

The  human  factors  analyses  of  the  usability  of  the  UCI  should  consider  how 
SAFOR  is  used  in  various  applications.  For  example,  does  the  IDA  analyst  want  to  finely 
control  the  movements  of  one  or  two  helicopters?  Does  the  AI  researcher  need  real-time 
explanations  of  the  internal  decisions  SAFOR  is  making?  Will  there  be  SUMEX-like  test 
for  other  user  groups? 

Testing  and  calibrating  SAFOR  behaviors  will  always  be  difficult,  mainly  because  it 
runs  only  in  real-time  (even  if  the  computer  is  powerful  to  speed  up  a  given  scenario,  there 
is  no  guarantee  that  the  approximations  made  in  vehicle  movements  might  not  change  the 
results).  Techniques  should  be  developed  that  assist  the  full-up  system  testing  of  SAFOR. 
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Also,  one  may  need  a  regular  program  of  manned  simulator  tests  to  provide  a  basis  for 
calibrating  die  behaviors  encoded  in  die  CISs. 

POTENTIAL  RECOMMENDATIONS 

PM  CATT  should  establish  programmatic  ties  and  maintain  commonality  with  the 
ARPA  SAFOR  research  efforts.  This  implies  developing  a  shared  baseline  system,  using  a 
common  programming  language,  and  establishing  a  program  to  educate  the  respective 
developers.  Developing  a  good  SAFOR  system  remains  a  learned  art 

PM  CATT  should  ensure  that  the  CCTT  SAFOR  is  readily  accessible  to  broad  user 
and  developer  communities.  The  key  factor  is  hardware  and  software  cost  which  can  be 
reduced  by  minimizing  the  need  for  expensive  compilers,  commercial  software,  or 
programming  expertise  that  would  have  to  be  specially  hired. 

COMMENTS  ON  THE  CURRENT  DEVELOPMENT  STRATEGY 

The  most  noteworthy  elements  of  the  development  strategy  are  the  efforts  to  involve 
proponents  and  users.  Clearly,  CCTT  must  end  up  with  validated  models  and  data.  The 
program  has  involved  the  appropriate  organizations  early  and  fully.  SUMEX  '93  is  a  good 
way  to  educate  the  code  developers.  Such  exercises  should  be  held  several  times  a  year. 

The  encoding  of  doctrine  into  the  Combat  Instruction  Sets  (CISs)  represents 
perhaps  the  most  profound  element  of  the  program.  If  successful,  the  CISs  will  become 
the  representation  of  doctrine,  and  the  means  by  which  new  doctrine  will  be  developed. 
The  risks  are  that  the  current  approach  will  capture  what  experts  say  they  would  do,  and  are 
not  based  on  experiments  using  manned  simulators.  Should  the  CISs  reflect  how  people 
fight,  or  should  they  represent  a  standard  to  train  against? 

The  exchange  of  personnel  among  the  IDT  and  Loral  sites  was  clearly  beneficial.  It 
underlines  the  need  for  the  CCTT  program  to  have  a  close  and  continuing  link  to  the 
various  research  efforts  and  expertise. 

The  study  of  how  ModSAF  would  be  re-engineered  is  valuable  for  two  reasons. 
First,  it  provided  an  independent  assessment  of  the  good  ideas  in  ModSAF.  Second,  any 
such  reexamination  is  likely  to  make  for  an  improved  product,  no  matter  how  much  or  little 
of  ModSAF  is  reworked. 

Being  able  to  maintain  traceability  from  requirements  through  development  is  a 
good  way  to  get  outside  people  involved,  and  to  manage  expectations.  The  panel 
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discussions  would  have  been  enhanced  by  more  detail  of  what  are  the  CCTT  SAFOR 
requirements. 

COMMENTS  ON  THE  PRESENTATIONS 

The  presentations  were  uniformly  informative,  and  the  presenters  generally  well- 
prepared.  Much  time  was  spent  on  areas  with  minor  bearing  on  the  key  issues.  The  1ST 
analysis  of  C  to  Ada  conversion  had  too  many  caveats  to  be  pertinent,  for  example.  The 
IDT  presentation  discussed  the  Trade  Study  at  length,  only  to  later  observe  that  it  is  now 
overtaken  by  events.  Also,  the  IDT  presentation  on  their  re-engineered  design  of  ModSAF 
could  have  discussed  more  the  CCTT  requirements  which  necessitated  the  redesign.  In 
particular,  how  much  of  the  redesign  effort  was  due  to  an  assumption  that  Ada  would  be 
used? 


» 
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COMMENTS  BY  PAUL  GORMAN 


The  panel  was  convened  to  inquire  into  the  cogency  of  developing  computer 
software  written  in  the  Ada  computer  language  for  the  Semi-Automated  Forces  (SAFOR) 
within  the  U.S.  Army  training  devices  termed  Close  Combat  Tactical  Trainer  (CCTT),  a 
subset  of  Combined  Arms  Tactical  Trainer  (CATT).  The  following  remarks  urge  that  PM 
CATT  reconsider  use  of  Ada  on  the  grounds  that,  at  a  time  when  change  is  the  order  of  die 
day,  Ada  code  may  render  CCTT  SAFOR  and  other  CATT  components  less  accessible  and 
mutable  than  C  or  C++. 

The  Ada  decision  had  been  taken  some  time  ago  on  the  grounds  that  (a)  Ada  is 
mandated  by  the  Department  of  Defense  and  the  governing  requirement  document,  (b)  Ada 
is  specifically  indicated  for  re-engineering  mature  software  ready  for  production,  in  that  it  is 
comparatively  error-free  or  error-correcting,  and  (c)  the  life-time  costs  for  maintaining  Ada 
would  be  less  than  if  written  in  any  other  language.  However,  that  Ada  decision  had  been 
conjoined  with  adopting  some  of  the  features  of  ModSAF,  an  ARPA-sponsored  modular 
approach  to  SAFOR  programming  not  written  in  Ada,  so  that  the  current  CCTT  program 
converts  the  best  features  of  ModSAF  to  an  essentially  Ada  architecture.  CATT  managers 
pointed  out  that  CCTT  is  moving  on  a  demanding  schedule  toward  production  and  issue  to 
the  force;  that  they  had  invested  a  year's  time  and  effort  in  production  of  the  SAFOR 
software  including  Ada;  and  that  scrapping  Ada  would  entail  at  least  six  months  delay  in 
fielding  CCTT. 

The  names  of  CCTT  and  CATT  reflect  their  original  intent  as  training  support 
mechanisms.  But  to  manage  these  now  exclusively  for  training  could  truncate  their 
centrality  for  supporting  research  and  development,  test  and  evaluation,  and  operational 
rehearsal.  Moreover,  their  Army  origin  and  focus  belies  their  importance  for  joint 
(multiservice)  applications.  Rhetoric  of  the  Defense  Science  Board,  and  of  a  number  of 
past  and  present  officials  of  the  Department  of  Defense,  embraces  such  broader  missions. 
Further,  the  recent  report  of  the  Senate  Appropriations  Committee  on  the  1994  Defense 
Appropriations  makes  it  evident  that  the  SAC  considers  intrinsically  valuable  the  digital 
battlefield  created  for  SIMNET,  the  predecessor  of  CATT,  and  intends  to  support  extension 
of  that  environment  beyond  the  funding  requested  by  the  Administration.  Narrowly 
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conceived  requirements  notwithstanding,  PM  CATT  can  realize  optimal  return  on  the 
CCn/CATT  investment  only  by  insuring  that  his  system  remains  accessible,  capable  of 
being  extended  readily  to  embrace  joint  training,  and  to  support  communities  of  other  users 
well  beyond  those  originally  contemplated.  Ada  appears  to  constrain  rather  than  enhance 
accessibility. 

SAPOR  will  assuredly  be  important  to  the  acceptability  and  usefulness  of  CCTT, 
and  ultimately  that  of  all  components  of  CATT.  However,  times  have  changed  since  the 
requirements  for  CCTT/SAFOR  wore  written.  Conceived  to  represent  the  canonical 
opponents  in  a  NATO- Warsaw  Pact  war,  SAFOR  must  now  be  mutable,  able  to  represent 
with  dispatch  and  facility  any  force  that  might  confront  U.S.  forces.  Moreover,  since 
many  SAFOR  applications  will  represent  U.S.  units,  SAFOR  platforms  must  be  readily 
changeable  to  reflect  the  continual  upgrade  in  sensors,  munitions,  and  other  capabilities 
contemplated  in  current  U.S.  defense  policy.  In  short,  criteria  for  SAFOR  software  ought 
to  accord  higher  value  to  accessibility  and  adaptability  than  to  life-cycle  maintainability. 

Last  May,  Lt  General  Forster,  the  Deputy  Acquisition  Executive  of  the  Army, 
signed  a  directive  requiring  all  Program  Managers  to  submit  a  simulation  plan  that 
specifically  considers  all  three  forms  of  simulation  (subsistent  or  real,  virtual  or  apparently 
real,  and  constructive  or  modeled).  Though  the  Army  has  stated  requirements  for  a  virtual 
simulation  for  Research,  Development,  Test  and  Evaluation  (RDT&E)  entitled  Battlefield 
Distributed  Simulation-Developmental  (BDS-D),  the  sole  virtual  simulation  presently 
available  is  SIMNET,  and  CCTT  offers  the  main  prospect  for  a  generic  synthetic  combined 
arms  environment  to  support  future  RDT&E.  SIMNET  has  demonstrated  that  a  virtual 
simulation  such  as  CCTT,  employed  with  SAFOR,  can  establish  die  context  for  RDT&E  of 
a  new  item  of  materiel,  from  establishing  its  military  worth  early  in  the  R&D  cycle  through 
testing  its  performance  prior  to  production  for  the  force.  But  Program  Managers  are  not 
likely  to  command  the  funds  or  the  programming  skills  required  for  Ada  code  to  insert  their 
materiel  into  such  an  environment.  Again,  accessibility  and  adaptability  of  the  CCTT  code 
appears  to  be  a  primary  measure  of  its  usefulness. 

A  very  current  illustration  of  the  foregoing  set  of  issues  is  presented  by  one  of  the 
premier  projects  of  DDR&E  Thrust  Panel  5,  the  21st  Century  Land  Warrior  (21  CLW). 
21  CLW  is  a  program  under  the  aegis  of  the  Army's  Natick  Research  and  Development 
Center  that  aims  at  fielding  an  integrated  set  of  equipment  for  individual  combatants: 
powerful  new  weapon(s),  computer-aided  command  and  control,  and  battle  dress  enhanced 
for  survivability.  The  simulation  plan  for  21  CLW  has  thus  far  included  only  constructive 
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models  yet  to  be  validated.  Even  if  these  models  were  to  prove  reliable,  it  is  not  clear  that 
they  could  reliably  portray  increases  in  effectiveness  that  would  accrue  through  use  of 
21  CLW,  and  it  is  virtually  certain  that  they  would  shed  no  light  cm  the  tough  questions  of 
man-machine  interface  inherent  in  equipment  that  combatants  wear  and  personally  cany,  or 
evaluate  prospects  of  mentally  overloading  the  dismounted  combatant  SIMNET  made  no 
provision  for  individual  combatants;  CCTT  presently  treats  dismounted  infantry  fire  teams 
as  a  SAFOR  entity,  but  not  as  individuals,  and  even  that  representation  is  not  validated  or 
verified.  What  is  plainly  needed  is  an  individual  portal  into  virtual  simulation — 
conceivably,  a  new  "system"  for  the  CATT  program — and  instrumentation  for  individual 
participants  in  subsistent  simulation  that,  taken  together,  will  enable  comprehensive 
simulation  of  21  CLW  to  compare  its  military  worth  against  current  equipment,  and  to 
assess  its  implications  fen-  doctrine  and  fence  structure.  Further,  since  modem  missions  fen 
U.S.  armed  forces  place  heavy  demands  on  dismounted  troops,  entity  level  SAFOR 
portrayal  of  dismounted  combatants,  friendly  or  enemy,  would  be  strategically  useful. 
I-Port  does  not  now  exist,  and  SAFOR  for  individual  combatants  requires  research  and 
development  at  the  P6.1-P6.2  (Science  and  Technology)  level.  Developers  of  such  tools 
will  almost  surely  find  onerous  working  with  an  Ada  encoded  CCTT. 

hi  implementing  CCTT  SAFOR  and  indeed,  in  addressing  other  similarly  important 
management  issues,  PM  CATT  must  consider  the  intended  primary  users  of  his  fielded 
system.  CATT  must  enable  training  on  a  synthetic  battlefield  of  heavy  forces  being  readied 
for  close  combat.  Most  users  of  CATT  will  be  National  Guardsmen  in  company  armories 
whose  attention  will  center  on  minor  tactics.  For  these,  SAFOR  can  and  should  portray 
opposing  forces  (Red  SAFOR)  to  establish  uniform  conditions  and  standards  for  tasks 
assigned  during  well-structured,  criterion-referenced  training  within  platoons.  SAFOR 
ought  also  to  enable  "tethered"  (Blue  SAFOR)  exercises  in  moving,  shooting,  and 
communicating  by  platoon  leaders  and  company  commanders. 

Whereas  USATRADOC  once  held  that  all  CCTT  exercises  would  employ  SAFOR, 
that  command  now  contemplates  using,  for  certain  critical  tasks,  manned  OPFOR  vehicular 
simulators  to  provide  appropriate  portrayal  of  novel  threats.  Instructors  of  tactics  will  no 
doubt  find  that  their  personally  controlling  SAFOR  puts  them  in  a  prime  position  to  assure 
heuristic  exercises  and  cogent  After  Action  Reviews.  Tools  for  increasing  an  instructor's 
control  over  SAFOR,  either  by  selective  manning  of  vehicles,  or  by  software  such  as  the 
"editor"  features  of  ModSAF,  seem  inherently  advantageous  fen*  teaching  small  unit  tactics 
and  techniques.  To  the  degree  that  embedding  ModSAF  in  Ada  impairs  that  accessibility 


and  adaptability,  to  that  degree  the  CCTT  SAFOR  software's  usefulness  for  training  will  be 
degraded. 

The  panel  heard  much  about  extending  the  automatical  of  SAFOR.  Yet,  one  should 
not  expect  Reservists  or  their  trainers  often  to  make  extensive  use  of  SAFOR  automated  to 
battalion  or  above.  CCTT  seems  to  have  been  asked  to  pay  too  much  attention  to  SAFOR 
requirements  recently  generated  by  Active  Component  users  who  seek  reliable,  highly 
autonomous  performance  by  SAFOR  to  support  high  visibility  exercises  of  brigades  and 
even  divisions.  The  research  project  (CCSIL)  briefed  by  Commander  McBride  of  ARPA 
probes  more  extensive  SAFOR  autonomy.  Yet,  extensively  aggregated  and  autonomous 
SAFOR  could  slight  the  behavioral  detail  at  die  entity  level  important  for  SAFOR  utility  in 
the  Reserve  Components,  the  very  sort  of  detail  controlled  by  the  modular  editors  of 
ModSAF.  The  panel  was  shown  examples  of  graceful  interfaces  between  SAFOR  and 
large,  constructive  models  of  war,  interfaces  that  permitted  selective  disaggregation  of  units 
within  the  model  to  the  entity  level,  and  interactive  resolution  of  concurrent  combat 
sequences.  It  seems  sensible  for  PM  CCTT  to  give  priority  in  his  SAFOR  development  to 
entity  level  behavior  and  small  unit  performance,  relying  on  ARPA  or  constructive  models 
to  furnish  higher  echelon  contexts  for  CCTT  exercises. 

The  panel  did  not  hear  about  SAFOR  connections  between  virtual  or  constructive 
simulation  and  subsistent  simulation.  At  the  Army's  Combat  Training  Center  in  Europe, 
brigades  now  train  with  one  subordinate  unit  in  the  subsistent  or  real  mode  of  simulation  at 
Hohenfels,  while  other  subordinates  participate  via  a  constructive  model  or  via  SIMNET. 
It  seems  important  for  the  participants  afield  to  be  able  to  observe  friendly  units  operating 
(in  constructive  or  virtual  simulations)  within  line  of  sight  or  within  sensor  range  on  either 
flank,  and  to  conduct  reconnaissance  of  OPFOR  threats  along  avenues  of  approach  that 
traverse  their  unit's  assigned  boundaries.  SAFOR  could  inject  entity  representations  into 
sensors  (e.g.,  radar  or  IR),  thereby  adding  to  the  scope  and  fidelity  of  simulation  at  the 
CTC,  and  provisions  should  be  made  for  such  interfaces  by  PM  CCTT. 

All  the  foregoing  suggests  that  CCTT  SAFOR,  far  from  being  a  mature  product 
ready  for  "type  classification,"  production  and  fielding,  is  and  should  remain  for  the 
foreseeable  future  an  evolving  assembly  of  software  tools  that  ought  to  be  highly  modular, 
very  accessible,  and  easily  changeable.  I  recommend  that  PM  CATT  reconsider  using  Ada, 
but  press  ahead  with  the  ModSAF  re-engineering  presently  under  way. 
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COMMENTS  BY  JOHN  LAIRD 


I  1 .  Can  the  same  SAFOR  products  support  both  the  R&D  community  and 

the  user  community?  If  yes,  what  are  the  products? 

Yes.  It  is  critical  to  both  of  these  communities  for  them  to  share  products. 

k  R&D  products: 

Over  die  next  four  years,  ARPA  will  be  spending  millions  of  dollars  on  advances  in 
SAF  technology  including  work  on  intelligent  forces;  communication,  command,  and 
control;  wide-area  simulation.  It  is  important  for  the  user  community  to  have  quick  access 
I  to  this  research. 

User  community  (CATTs  for  example)  products: 

The  development  of  CCTT  SAFOR  will  lead  to  the  creation  of  the  following: 

|  •  A  well-engineered  SAFOR.  This  will  include  the  simulation  engine  as  well  as 

the  control  logic  for  the  SAF  entities.  Both  of  these  will  be  valuable  to  the 
research  community.  The  first  as  a  platform  for  interfacing  with  the  DIS 
environment  The  second  as  a  base-line  for  behavior  of  platoon  and  company- 
level  behavior.  Other  components,  such  as  the  terrain  database  and  the  inter- 
visibility  calculation  software  will  also  provide  useful  base-lines  for  research  in 
these  areas. 

•  A  database  of  CISs  and  their  associated  audit  trails.  This  information  will 
greatly  help  anyone  trying  to  do  research  in  automated  forces. 

The  critical  question  is  whether  the  sharing  should  occur  at  the  level  of  individual 
components,  or  of  complete  software  systems.  I  believe  that  maximal  sharing  is  important 
(of  as  complete  of  software  systems  as  possible).  Thus,  we  want  the  research  community 
to  directly  use  the  products  of  the  user  community.  I  do  not  expect  the  user  community  to 
be  able  to  directly  use  the  products  of  the  research  community,  although  it  is  important  that 
pieces  of  products  from  the  research  community  should  be  demonstratable  within  the  user 
community  software. 
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Rationale  for  maximal  sharing: 

•  If  Ac  research  community  is  not  using  the  products  of  the  user  community,  the 
research  community  may  address  problems  that  are  tangential  to  the  concerns 
of  the  user  community. 

•  The  amount  of  funding  available  for  continued  development  of  SAF 
environments  will  be  limited.  It  will  be  difficult  for  the  research  community  to 
have  access  to  a  well-engineered  SAF  system  unless  it  comes  from  the  user 
community. 

•  The  comparison  of  research  results  to  a  meaningful  baseline  will  be  difficult 
without  the  research  community  using  die  user  community  SAFOR. 

•  There  is  the  potential  for  results  of  the  research  community  to  be  demonstrated 
within  the  context  of  the  user  community  SAFOR.  For  example,  if  an 
alternative  behavior  control  system  is  developed  in  the  research  community,  it 
could  be  tested  within  the  user  community  (training  centers)  on  real  data.  In 
general,  sharing  a  common  environment  will  increase  die  research  communities 
access  to  realistic  data.  If  die  development  goes  on  in  separate  environments, 
there  is  too  great  a  potential  for  minor  incompatibilities  to  make  integration  very 
difficult. 

•  The  shared  expertise  in  a  single  software  environment  will  greatly  increase  the 
possibility  for  people  to  move  between  the  two  communities — greatly  aiding 
technology  transfer. 

•  Finally,  the  SAFOR  technology  is  immature.  After  the  CCTT  SAFOR  is 
developed,  it  will  have  to  be  extended  for  the  other  CATT  programs,  as  well  as 
other  services.  Already,  many  of  the  requirements  for  CCTT  push  it  into 
uncharted  waters,  making  a  continual  infusion  of  results  from  the  research 
community  a  critical  component  of  its  development. 

As  pan  of  developing  a  single  software  environment  that  is  shared  between  the  user 
and  the  research  community,  that  environment  must  have  well  documented  components  and 
interfaces  so  that  the  research  community  can  easily  modify  the  software.  The  current 
CCTT  SAFOR  development  methodology  is  consistent  with  this  need. 

2 .  What  software  approach  should  be  used  for  CCTT  SAFOR  considering 
the  needs  of  both  the  R&D  community  and  the  user  communities? 

The  software  methodology,  independent  of  the  language,  will  determine  the  ability 
of  CCTT  SAFOR  to  meet  the  needs  of  the  user  community  (life  cycle  maintainability, 
reliability).  The  selection  of  the  language  is  clearly  secondary.  My  impression  is  that  the 
current  software  methodology  is  excellent  and  will  lead  to  good  maintainability  and 
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reliability.  Thus,  we  are  able  to  look  at  other  issues,  the  most  important  being  usability  and 
flexibility  by  the  research  community.  Here,  Ada  is  inferior  to  C: 

•  There  is  an  established  base  of  C  programmers  in  the  research  community. 
Most  of  the  major  engineering  universities  teach  C  in  introductory 
programming  courses.  C  has  become  the  standard  for  engineering  software — 
all  large  engineering  software  packages  are  being  written  in  C  (such  as 
CAD/CAM  systems).  There  is  little  if  any  research  work  done  in  Ada. 

•  The  entry  cost  of  using  a  C-based  system  is  much  lower  than  Ada.  There  are 
even  high-quality  free  C  compilers  available  on  most  UNIX  systems  (GNU). 

•  The  software  development  cycle  of  recompiling  is  much  less  in  C.  This  is 
critical  in  a  research  environment  where  software  is  developed  incrementally. 
Thus,  I  recommend  adopting  C  for  the  development  of  the  COT  SAFOR. 

What  has  to  be  considered  is  the  life-cycle  of  the  SAFOR  project  past  the  delivery 
of  the  CCTT  SAFOR.  Thus,  the  system  must  be  designed  for  the  infusion  of  results  from 
the  research. 

3 .  What  products  are  available  from  other  programs? 

There  do  not  appear  to  be  any  other  products  that  the  CCTT  SAFOR  team  has 
missed. 

4.  What  strategy  of  specific  steps  should  the  Program  Manager,  CATT, 
take  to  build  community  consensus  and  to  produce  a  product  that  will 
support  CATT  programs  other  than  CCTT? 

Nothing  special  recommended  here. 

5 .  What  strategy  should  the  Program  Manager,  CATT,  take  to  implement 
the  CCTT  SAFOR? 

•  Stay  the  course  on  the  methodology  for  software  development,  VVA,  building 
the  CIS  database. 

•  Adopt  C  as  the  language  for  implementing  CCTT  SAFOR. 

•  Continue  to  have  close  ties  with  the  research  community  such  as  the 
relationship  between  SAIC  and  LADS. 

•  Expand  the  ties  to  include  the  work  on  behavior  representation. 


6 .  Other  issues: 

ModSAF  development  must  continue  to  be  funded  over  the  next  3-4  years  to 
support  the  research  community  until  CCTT  SAFOR  is  available. 
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COMMENTS  BY  DUNCAN  MILLER 

As  the  complexity  of  the  SAF  development  issues  became  apparent  during  our 
discussions,  the  peer  review  panel  paused  to  confront  the  issue  of  how  broadly  we  should 
interpret  the  questions  we  had  been  asked  to  address.  We  decide  to  focus  on  how  to 
maximize  the  chances  of  succeeding  with  SAF  development  in  the  long  run,  rather  than  on 
how  to  fulfill  die  immediate  needs  of  die  COT  program. 

This  is  a  crucial  point,  because  SAF  is  by  no  means  a  mature  technology.  SAF 
technology  is  going  to  continue  to  evolve  for  at  least  the  next  several  years,  and  the  R&D 
community  will  need  to  be  involved  in  this  process  for  it  to  be  successful.  ARPA  is 
already  counting  on  some  substantial  extensions  of  SAF  technology,  especially  in  the  area 
of  representations  of  decision-making  and  command  and  control  functions,  for  WISSARD 
IFOR  and  STOW,  among  other  programs.  War  Breaker  will  almost  certainly  make  use  of 
these  developments,  as  well. 

As  SAF  technology  grows,  it  will  become  increasingly  important  that  researchers 
build  their  extensions  cm  a  solid,  accepted  base  of  code.  We  have  already  reached  the  point 
where  it  is  prohibitively  expensive  for  researchers  to  reinvent  the  large  body  of  existing 
work,  even  for  a  program  the  size  of  CCTT.  Increasingly,  they  must  build  on  what  is 
there,  adding  and  modifying  modules  where  necessary,  but  not  recreating  these  modules 
where  changes  in  functionality  are  not  needed. 

In  general,  the  panel  was  favorably  impressed  with  the  ModSAF  architecture,  with 
the  degree  to  which  the  Integrated  Development  Team  had  accepted  and  adopted  this 
architecture,  and  with  the  improvements  they  proposed  to  add  for  CCTT.  If  the  approach 
we  saw  presented  is  executed  well,  CCTT  SAF  should  become  the  new  foundation  for 
SAF  development  for  the  next  few  years.  For  this  to  occur,  however,  the  code  must  be 
easily  transportable,  accessible,  and  affordable  to  the  R&D  community,  the  Combat 
Developments  community,  and  the  Test  and  Evaluation  community.  All  of  these 
communities  share  the  need  to  access  and  modify  certain  modules  within  the  code  for 
various  purposes. 

This  brings  us  to  the  central  question  of  the  language  in  which  CCTT  SAF  is  to  be 
written  and  the  tools  and  support  modules  it  requires.  If  CCTT  SAF  is  implemented  only 
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in  an  Ada  environment,  the  number  of  organizations  that  can  deal  with,  and  modify,  the 
base  of  code  will  be  very  limited.  ARPA  probably  will  not  be  able  to  use  an  Ada-based 
CCTT  SAF  in  its  programs,  since  very  few  of  its  contractors  are  equipped  to  deal  with 
Ada.  This  is  true  from  the  standpoint  of  availability  of  experienced  personnel  and  tools,  as 
well  as  from  a  cost  and  schedule  standpoint 

I  believe,  and  it  appeared  that  all  erf  the  other  panelists  also  believe,  that  it  would  be 
best  if  the  CCTT  SAF  were  developed  and  maintained  in  C,  with  appropriately  rigorous 
levels  of  documentation  and  validation  of  the  algorithms  and  the  code.  As  new  capabilities 
emerge  from  R&D  programs,  they  will  have  to  be  adapted,  tested,  documented,  and 
validated  for  incorporation  into  CCTT  and  subsequent  CATT  programs,  but  this  is  a 
process  that  must  be  carried  out  in  any  case  for  a  production  system. 

The  other  alternative  we  discussed  was  maintaining  two  parallel  systems,  an  R&D 
version  in  C  and  a  production  version  in  Ada,  trying  to  keep  them  as  synchronized  as 
possible.  Such  an  approach  would  prove  cumbersome  and  expensive,  at  best  At  any 
given  point  in  time,  there  are  bound  to  be  discrepancies  in  the  capabilities  of  the  two 
systems  and  in  the  way  particular  algorithms  are  implemented.  These  discrepancies  would 
make  code  verifications  and  performance  comparisons  difficult,  and  would  make  it  very 
hard  to  interpret  the  results  of  tests  conducted  with  differing  versions  of  the  software. 

If,  after  considering  our  recommendations,  it  is  concluded  that  CCTT  SAF 
development  must  be  done  in  Ada,  we  suggest  that  STRICOM  be  prepared  to  undertake  at 
least  one  additional  round  of  SAF  enhancement  before  CCTT  is  fielded.  Over  the  next  two 

to  three  years,  we  believe  that  ARPA  programs  will  yield  enough  important  new  SAF 

♦ 

capabilities  that  such  enhancements  will  be  well  warranted. 

Finally,  it  was  noted  that  the  development  of  the  code  to  support  some  1200  SAF 
entity  behaviors,  which  require  an  average  of  10  pages  of  English  narrative  to  describe,  is 
going  to  make  CCTT  SAF  the  largest  representation  of  intelligent  human  behavior  ever 
undertaken.  This  is  a  daunting  prospect  The  sheer  magnitude  of  the  effort  reinforces  our 
point  that  no  other  programs  in  the  foreseeable  future  are  going  to  be  able  to  afford  to 
recreate  this  corpus  of  knowledge.  They  will  have  to  build  upon  what  the  CCTT  program 
has  achieved.  It  is  imperative  that  this  weak  be  shareable  across  all  of  the  communities  that 
need  access  to  DIS  technology.  We  think  this  access  will  be  possible  only  if  the 
implementation  is  done  in  C,  the  closest  thing  we  now  have  to  a  universal  language  in 
computer  science,  but  with  the  Systems  Engineering  discipline  and  documentation 
embodied  in  MIL  STD  2167A. 


The  above  comments  focused  primarily  on  the  Ada  language,  programming 
environment,  and  tools  as  barriers  that  would  inhibit  or  preclude  the  involvement  of  large 
segments  of  the  R&D  community  in  further  development  of  SAF  technology.  While  these 
are  the  primary  barriers,  they  are  not  the  only  barriers.  The  injudicious  selection  of  rule- 
based  software  could  have  a  similar  effect 

I  urge  that  to  the  extent  that  rule-generation  tools  and  a  rule-processing  engine 
become  a  key  component  of  CCTT  SAF,  the  selection  of  these  tools  should  also  be 
considered  from  the  standpoint  of  other  programs  and  other  developers.  For  all  die  reasons 
cited  above,  these  tools  will  become  an  integral  part  of  the  SAF  environment  on  which 
others  must  build.  Great  care  should  be  taken  to  ensure  that  they  are  available  at  reasonable 
cost  for  a  variety  of  computing  platforms.  The  government  should  consider  acquiring  the 
rights  to  use  these  tools  in  future  extensions  of  SAF,  both  for  R&D  purposes  and  for 
production  use,  so  that  they  can  be  furnished  to  future  developers  as  part  of  the  SAF 
software  package. 


> 


> 


> 
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COMMENTS  BY  ROBERT  RICHBOURG 


The  basic  framework  I  have  used  to  try  to  answer  the  questions  is  that  whatever 
decisions  are  reached,  they  must  have  a  favorable  impact  on  the  success  of  the  program, 
both  in  die  long  and  short  terms.  Long-term  success  is  the  more  important  of  the  two  and 
can  be  measured  by  the  characteristics  of  the  eventual  SAFOR  product  It  must  be 
acceptable  by  the  user  community  (in  the  widest  sense),  be  applicable  to  other  programs 
within  the  CATT  family  as  well  as  contribute  to  basic  research  questions  in  the  larger 
community,  and  be  easily  extensible  as  new  results  become  available.  While  the  long-term 
success  is  of  paramount  importance,  the  short-term  results  are  also  important;  a  short-term 
disappointment  will  greatly  diminish  the  chances  of  a  long-term  success.  The  short-term 
indicators  include  a  program  that  can  be  delivered  on  time,  within  budget,  and,  most 
importantly,  can  meet  the  stated  needs  of  the  program.  Trying  to  put  all  these  concerns  into 
a  few  words,  the  program  must  be  such  that  the  widest  community  (both  R&D  and 
development)  develops  and  feels  a  sense  of  ownership  for  a  product  that  has  been 
engineered  using  the  best  available  notions  from  software  engineering. 

1 .  Can  the  same  SAFOR  products  support  both  the  R&D  and  user 
communities? 

Without  question,  the  deliverables  from  this  program  can  be  used  by  both 
communities,  and  they  have  wider  applicability  to  commercial  enterprise  as  well.  The  most 
important  product  to  come  from  the  CCTT  SAFOR  effort  may  well  be  the  documented, 
electronic  codification  of  behaviors  at  the  various  operational  echelons  (from  individual 
platform  through  brigade).  A  credible  functional  description  for  military  behaviors  has 
been  a  stumbling  block  for  many  programs  in  the  past  and  could  still  be  one  well  into  the 
future.  The  CIS  specification  should  alleviate  this  problem.  Moreover,  the  CIS  will 
constitute  an  important  source  of  behavioral  description  (under  a  wide  set  of  conditions) 
that  should  be  of  great  value  in  further  explorations  into  understanding  general  human 
behaviors.  Similarly,  the  architecture/methodology  to  utilize  the  behavioral  specifications 
(the  CIS)  will  have  wide  interest  While  such  an  architecture  will  not  constitute  a  proof  of 
the  human  reasoning  process,  it  will  constitute  an  existence  proof  of  a  method  that  does 
work  (mixing  low-level  FS  A  mechanisms  with  high-level,  rule-based  techniques).  Again, 
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the  architecture  as  well  as  the  CIS  themselves  should  prove  useful  in  any  area  that  requires 
a  model  of  human  behavior. 

The  actual  software  (source  and  executables)  may  have  less  widespread 
applicability  than  the  CIS  and  CIS  architecture.  However,  they  should  still  prove  useful  to 
the  R&D  community  as  a  testbed  for  die  exercise  of  new  ideas.  Applicability  to  die  military 
user  communities  will  be  more  direct  Military  education  could  use  SAFOR  as  the  players 
who  reenact  past  battles,  as  we  have  already  seen  in  73  Easting.  The  educational  benefit 
could  be  enhanced  by  a  SAFOR  enabled  "what-if*  capability  for  history.  SAFOR  can  be 
used  for  other  educational  purposes,  such  as  trying  to  teach  military  students  how  to 
identify  an  OPFOR  (the  SAFOR)  center  of  gravity.  Clearly,  the  training  community  can 
benefit  from  continued  use  of  the  SAFOR.  New  doctrine  and  systems  can  be  tested  and 
refined  based  on  SAFOR  (both  as  OPFOR  and  friendly  forces).  The  analysis  community 
already  relies  on  a  form  of  (aggregated)  SAFOR  that  will  be  improved  by  producing  more 
capable  computer-controlled  force.  The  logistics  community  should  rely  on  SAFOR  to  a 
large  extent  in  the  exercise  of  both  support  and  mobility  planning.  As  an  example,  exercise 
of  a  port  clearing  plan  has  little  training  value  for  human  equipment  operators  but  has  high 
value  for  those  who  must  devise  and  refine  the  plan.  SAFOR  could  be  used  for  such 
purposes.  SAFOR  can  also  prove  helpful  in  the  examination  of  operational  and  strategic 
questions,  given  a  sufficiently  high  level  CIS  specification.  As  an  example,  suppose 
SAFOR  are  used  to  model  an  ally  (on  the  friendly  flank)  who  uses  tactics  typically 
associated  with  the  OPFOR  (the  Syrians  in  Desert  Storm).  SAFOR  could  be  used  to 
answer  many  questions  in  such  cases,  including  those  that  revolve  around  an  ally  who 
suddenly  decides  to  change  allegiance  mid-battle. 

Given  a  modification  in  some  of  the  CIS  specifications,  the  SAFOR  could  also 
apply  to  commercial  purposes.  Airborne  SAFOR  could  be  used  to  train  air  traffic 
controllers.  DI  SAFOR  could  help  train  law  enforcement  personnel  for  riot,  hostage,  and 
other  situations  (Waco,  Texas?).  Vehicular  SAFOR  would  be  useful  to  city  planners  when 
designing  transportation  networks. 

In  short,  the  CCTT  SAFOR  effort  should  find  application  in  many  areas. 

2.  What  software  approach  should  be  used  for  CCTT  SAFOR, 
considering  the  needs  of  both  the  R&D  and  user  communities? 

All  communities  will  best  be  served  by  a  software  system  that  strictly  adheres  to  the 
commonly  accepted  principles  of  "good"  software  engineering  practice.  There  are  several 
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programming  styles  that  could  be  applied  to  this  program  including  procedure-oriented, 
object-oriented,  logic-oriented,  rule-oriented,  or  constraint-oriented.  The  developers  in  the 
program  are  charged  with  producing  a  large  (over  100K  SLOC),  "industrial-strength" 
program  that  will  function  in  a  complex  domain.  Without  producing  a  text  on  software 
engineering,  I  simply  state  the  commonly  accepted  view  that  the  object-oriented  style  is  best 
suited  for  such  programs.  Given  that  the  object-oriented  style  will  be  used,  there  are 
several  characteristics  that  should  be  required  in  the  implementation  language.  These 
include  provisions  for  abstraction,  encapsulation,  modularity,  hierarchical  capabilities, 
strong  typing,  concurrency  support,  and  enabling  persistence.  While  the  implementation 
language  need  not  support  all  of  these,  supporting  most  of  them  will  be  helpful  in  using  die 
object-oriented  style. 

Other  constraints  on  the  implementation  language  are  more  pragmatic.  It  must 
generate  fast,  efficient  code.  The  goals  for  the  number  of  entities  to  be  "on  the  net”  are 
very  ambitious  and  cannot  be  met  by  an  implementation  language  that  makes  too  many 
sacrifices  in  execution  speed.  The  language  must  have  a  wide  base  of  support.  The  R&D 
community  is  concerned  about  the  issues  of  additional  cost,  both  in  acquisition  of  new 
software  and  in  training  people  to  use  new  software.  In  summary,  the  perfect  language  for 
the  CCTT  SAFOR  program  would  support  software  engineering  principles  (by  reliance  on 
the  object-oriented  paradigm),  produce  fast,  efficient  code,  and  be  widely  available  in  both 
the  production  and  R&D  communities.  Both  the  R&D  and  the  production  communities 
must  have  access  to  the  language.  The  product  of  the  production  effort  must  be  accessible 
by  the  R&D  community  so  that  they  can  have  a  testbed  to  generate  new  results  (which  will 
be  transferred  back  to  the  production  environment).  Actual  software  transfers  from  the 
production  community  to  the  R&D  community  while  concepts  and  methodology  transfer 
60m  the  R&D  community  back  into  the  production  environment 

From  the  presentations  at  the  peer  review,  it  seems  that  the  R&D  community  has  a 
preference  for  C,  a  language  that  is  not  object-oriented,  based  primarily  on  the  wide 
availability  of  both  C  environments  and  programmers.  The  IDT  advocates  use  of  Ada,  an 
object-based  but  not  object-oriented  language,  based  on  concern  for  software  engineering 
issues.  Remember  that  the  dominating  factor  in  the  quality  of  code  production  is  the 
skill/talent  of  the  individual  programmer.  A  talented  software  engineer  will  produced  well- 
engineered  code  given  any  high-level  language.  The  real  software  engineering  issue  here  is 
deciding  to  what  degree  does  the  chosen  language  encourage  the  average  programmer  to 
produce  a  well-engineered  product  While  use  of  Ada  will  not,  by  itself,  guarantee  a  good 
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software  engineering  effort,  it  was  designed  to  encourage  and  enforce  the  use  of  good 
software  engineering  practice  as  it  was  understood  in  the  late  1970's  and  early  1980’s.  The 
same  can  not  be  said  of  C;  use  of  good  software  engineering  principles  in  this  language  is 
more  a  matter  of  management  enforcement 

In  an  effort  to  recommend  an  implementation  language,  I  have  considered  four 
alternatives;  Ada,  Ada  9X,  C,  and  C++.  Given  any  language  choice,  I  assume  that  the  IDT 
will  continue  to  rely  on  the  same  set  of  tools  to  perform  OOA  and  OOD,  so  that  the  degree 
to  which  any  language  "dovetails’’  with  the  OOA/OOD  result  is  also  an  issue. 

a.  Ada: 

Ada  is  object-based  but  not  object-oriented  (as  it  does  not  support  inheritance)  and  it 
is  not  well  established  within  the  R&D  community.  Public  domain  Ada  compilers  are 
available  (Gnu  project)  but  these  are  not  subject  to  the  formal  validation  process.  Thus, 
compiler  acquisition  costs  are  not  large  issues.  However,  training  costs  to  produce  Ada 
programmers  in  the  R&D  community  will  still  have  an  impact  (more  time  and  effort  than 
dollars).  Ada  code  is  generally  slower  than  equivalent  C  code.  An  Ada  implementation 
would  fit  well  with  the  products  from  IDT  OOA  and  OOD.  Ada  was  designed  to  encourage 
programmer  use  of  software  engineering  principles. 

b.  Ada  9X: 

Ada  9X  is  the  fully  object-oriented  improvement  of  Ada  and  should  thus  be  more 
useful  in  the  object-oriented  style  of  program  development.  Public  domain  Ada  9X 
compilers  should  be  available  by  31  December  1993  (again  from  the  Gnu  program),  but 
these  will  not  be  subject  to  formal  validation.  Programmer  familiarity  within  the  R&D 
community  remains  an  issue.  Further,  Ada  9X  is  a  new  language  that  does  not  enjoy  a 
wide  support  base  in  any  community  and  has  not  yet  been  subject  to  public  scrutiny  to 
ensure  an  error-free  compiler  or  environment  I  assume  that  Ada  9X  execution  speed  is 
similar  to  that  of  Ada  code.  An  Ada  9X  implementation  should  fit  exactly  with  the  results 
of  IDT  OOA  and  OOD.  Ada  9X  should  encourage  a  high  degree  of  good  software 
engineering  practice. 

c.  C: 

C  is  procedure-oriented,  not  object-oriented  for  many  reasons.  C  is  widely 
supported  and  available  in  both  R&D  and  commercial  communities.  C  code  generally 
executes  very  fast  As  C  is  not  object-oriented,  it  may  not  align  well  with  the  results  of 
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IDT  OOA  and  OOD.  C  was  not  designed  with  promotion  of  good  software  engineering 
principles  in  mind  and,  in  many  cases,  the  "shortcuts"  available  in  C  can  actually  encourage 
the  programmer  to  eschew  established  software  engineering  practice,  frustrate  management 
attempts  to  enforce  software  engineering  principles,  and  produce  runtime  errors  that  are 
very  difficult  to  locate. 

d.  C++: 

C++  is  object-oriented  and  enjoys  wide  use  and  support  in  both  the  R&D  and 
commercial  communities.  C++  code  generally  executes  fast,  but  more  slowly  than 
conventional  C  code.  As  C++  is  fully  object-oriented  (although  it  does  not  support 
persistence)  is  should  fit  well  with  the  results  from  IDT  OOA  and  OOD.  While  not 
designed  with  software  engineering  support  in  mind,  C++  is  object-oriented,  which  should 
aid  in  quality  software  production.  Also,  as  C++  should  be  able  to  reasonably  reflect  the 
results  of  OOA  and  OOD,  it  should  encourage  good  software  engineering  practice. 

Recommendation:  Select  C++  as  the  implementation  language. 

A  second  issue  of  concern  regarding  the  implementation  involves  the  use  of  the 
COTS  product  RTWorks  to  implement  the  rule-based  component  of  the  software.  Again, 
acquisition  and  training  costs  for  the  R&D  community  cause  some  problems.  An 
alternative  in  this  area  is  the  C  Language  Integrated  Production  System  (CLIPS),  a  GOTS 
product  that  was  built  at  NASA  to  allow  the  implementation  of  Al-type  systems  (RBS  and 
expert  systems)  on  conventional  hardware.  A  companion  product  is  CLIPS  Object- 
Oriented  Language  (COOL)  which  allows  object-oriented  concepts  to  be  used  with  the 
CLIPS  environment.  These  products  are  available  free  of  cost  to  government  agencies  and 
at  nominal  cost  to  others  (approximately  $350).  While  a  firm  recommendation  to  use 
CLIPS  cannot  be  made  without  specific  knowledge  of  the  IDT  expected  benefits  from 
using  RTWorks,  it  is  an  option  that  deserves  some  examination. 

3 .  What  products  are  available  from  other  programs  that  could  also  be 
useful  in  developing  CCTT  SAFOR? 

In  general,  the  DMSO  Survey  of  SAFOR  and  the  IDT  together  seem  to  have 
covered  this  question  well.  One  small  addition  to  those  systems  already  examined  is 
CUPS,  as  discussed  above.  Also,  encoding  the  CIS  is  a  large  project  in  constructing  a 
knowledge  base  of  rare  size  (very  large),  high  complexity,  and  intended  for  wide  and 
general  use.  Doug  Lenat's  Cyc  project  at  MCC  may  offer  some  insight  into  the  issues  and 


methodology  involved  when  constructing  such  a  base  of  knowledge  that  should  be 
generally  useful. 

4.  and  5.  How  should  the  PM  CATT  proceed  to  build  community 
consensus  and  build  a  CCTT  SAFOR  that  will  be  useful 
well  into  the  fiiture? 

In  general,  the  program  seems  to  be  progressing  exceptionally  well  and  most 
recommendations  in  this  area  involve  continued  or  expanded  use  of  practices  that  have 
already  proven  successful. 

a.  Continue  to  use  the  spiral  development  technique. 

b.  Using  people  rather  than  documentation  to  effect  information  exchange  is  a 
success.  Continue  the  relationship  between  the  IDT  and  LADS  and  consider 
opportunities  to  include  personnel  from  the  R&D  community  (visiting 
scholars)  in  the  program. 

c.  The  SUMEX  worked  well  and  should  be  continued  on  a  regular  basis.  Again, 
consider  opportunities  to  involve  selected  researchers  from  the  R&D 
community  in  the  program.  This  could  have  wider  impact  than  just  for  the 
CCTT  SAFOR  development 

d.  Take  a  more  active  role  in  funding  research.  At  some  point,  ARPA  emphasis 
will  be  shifted  to  other  areas  and  CCTT  should  have  a  mechanism  in  place  to 
fill  the  void. 

e.  Insist  on  tightly  specified,  well  documented  interfaces  for  the  IDT  software. 
Similarly,  emphasize  modularity  to  encourage  "plug-in"  use  of  the  CCTT 
SAFOR  products. 

f .  Insist  on  strict  standards  for  data  abstraction;  maintain  all  data  separate  from 
any  code  that  uses  it.  Apply  this  to  the  knowledge  base  created  as  the  CIS  as 
well.  Documentation  is  necessary. 

g.  Continue  soliciting  review  and  feedback  from  the  R&D  community  both  to 
enhance  their  feeling  of  ownership  for  the  program  as  well  as  to  get  their 
insights. 

h.  Insist  that  architecture  and  methodology  are  as  well  documented  as  the  code 
itself.  These  are  major  reusable  products. 

i.  Place  a  strong  emphasis,  including  incremental  user  review,  on  the 
construction  of  system  interfaces.  A  poor  interface  can  ruin  an  otherwise 
exceptional  product  while  a  strong  interface  can  support  a  marginal  effort  The 
interface  deserves  a  lot  of  attention  and  effort 


j.  Maintain  the  same  high  levels  of  effort  and  productivity  and  keep  up  the  great 
work! 
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BIOGRAPHICAL  SKETCHES  OF  PANEL  MEMBERS 


Dr.  Philip  S.  Anton  is  a  member  of  the  technical  staff  at  the  MITRE  Artificial 
Intelligence  Technical  Center.  His  research  interests  include  behavioral 
representation,  distributed  simulation,  computational  neuroscience,  and  neural 
network  modeling.  Dr.  Anton  received  his  B.S.  in  Engineering  from  UCLA,  and 
his  M.S.  and  PhD.  from  the  University  of  California  at  Irvine  in  Information  and 
Computer  Science,  specializing  in  Artificial  Intelligence  and  Computational 
Neuroscience.  He  is  a  member  of  IEEE,  ACM,  INNS,  and  CPSR. 

Peter  Brooks  is  a  member  of  the  Strategy,  Forces,  and  Resources  Division  of  the 
Institute  for  Defense  Analyses  in  Alexandria,  Virginia.  He  received  the  A.B. 
degree  in  mathematics  from  Princeton  University,  and  the  M.S.  and  Ph.D.  degrees 
in  mathematics  from  Stanford  University.  Prior  to  joining  IDA,  he  held  a  research 
position  with  the  Department  of  Defense.  His  recent  work  includes  contributions  to 
the  development  of  new  analytic  methods  for  use  with  SIMNET  and  DIS  exercises, 
a  workstation-based  smart  minefield  simulator,  and  test  procedures  feu  Semi- 
Automated  Forces. 

Gen.  Paul  F.  Gorman,  U.S.  Army  (Retired),  is  Visiting  Professor  of  Computer 
Science,  University  of  Virginia,  and  a  consultant  on  military  training  for  the 
Institute  for  Defense  Analyses,  and  for  the  Defense  Science  Board.  He  has 
contributed  to  the  development  of  virtual  tactical  engagement  simulation  from  its 
inception. 

John  E.  Laird  received  his  B.S.  from  the  University  of  Michigan  in  1975  and  his  Ph.D. 
in  Computer  Science  from  Carnegie  Mellon  University  in  1983.  He  is  currently  an 
Associate  Professor  in  the  Electrical  Engineering  and  Computer  Science  Department 
of  the  University  of  Michigan  and  Director  of  the  Artificial  Intelligence  Laboratory. 
His  primary  research  interests  are  in  the  nature  of  the  architecture  underlying 
artificial  and  natural  intelligence.  His  work  is  centered  cm  the  development  and  use 
of  Soar,  a  general  cognitive  architecture.  Most  recently  he  is  the  principal 
investigator  on  the  Soar/IFOR  component  of  WIS  SARD/IFOR.  The  goal  of  this 
project  is  to  develop  intelligent  forces  within  tactical  air-to-air  engagements. 
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Duncan  C.  Miller  holds  four  degrees  from  MIT,  including  the  Doctor  of  Science  in 
Mechanical  Engineering.  His  principal  areas  of  study  included  control  theory, 
human  operator  performance  modeling,  human  factors,  and  perceptual  psychology. 
At  Bolt  Beranek  and  Newman  Inc.  (Cambridge,  MA,  1963-1993),  Dr.  Miller 
formed  and  managed  the  group  that  developed  the  protocols  and  software  for 
SIMNET.  He  is  a  member  of  the  Distributed  Interactive  Simulation  Standards 
Steering  Committee,  which  refined  the  SIMNET  protocols  into  IEEE  Standard 
1278-1993  (Standards  for  the  Interoperability  of  Defense  Simulations).  He  has 
served  on  a  number  of  advisory  committees,  boards,  and  panels,  including  the 
Naval  Research  Advisory  Committee  Panel  on  the  Impact  of  Advancing 
Technology  on  Exercise  Reconstruction  and  Data  Collection  (1990-91),  die  Defense 
Science  Board  Task  Force  on  Simulation,  Readiness,  and  Prototyping  (1992),  the 
Congressional  Office  of  Technology  Assessment  Defense  Modeling  and  Simulation 
Project  Advisory  Panel  (1993-94),  and  die  Air  Force  Science  Advisory  Board  Joint 
Modeling  and  Simulation  Systems  Review  Panel  (1994).  Dr.  Miller  is  currendy 
leading  a  small  group  of  experts  at  MIT  Lincoln  Laboratory,  facilitating  cooperation 
and  technical  exchange  across  government  programs  in  such  areas  as  Distributed 
Interactive  Simulation  standards  and  architectural  issues;  data  flow  management  in 
large  interactive  networks;  information  management  for  large,  muldsite  exercises; 
C3  simulation  protocols;  and  other  issues  involved  in  interfacing  virtual,  live,  and 
constructive  simulations. 

Robert  Richbourg  was  commissioned  as  an  officer  in  the  Regular  Army  in  1976  after 
graduation  as  a  Distinguished  Military  Graduate  from  the  ROTC  program  at 
Wake  Forest  University.  He  has  served  on  battalion  staff  sections  in  various 
positions  and  commanded  a  HAWK  missile  battery  in  the  Federal  Republic  of 
Germany.  His  military  schooling  includes  the  Air  Defense  Artillery  Officer's  Basic 
and  Advanced  Courses  as  well  as  the  Command  and  General  Staff  College.  In 
1984,  he  earned  a  Computer  Science  Master's  Degree  as  the  top  graduate  in  the 
Computer  Science  curriculum  at  the  Naval  Postgraduate  School.  He  became  the 
first  Computer  Science  Ph.D.  graduate  of  the  Naval  Postgraduate  School  in  1987. 
Lieutenant  Colonel  Richbourg  is  currently  an  Academy  Professor  at  the 
United  States  Military  Academy,  West  Point,  where  he  has  served  as  the  Director 
of  the  Office  of  Artificial  Intelligence  Analysis  and  Evaluation  since  1988. 
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APPENDIX  C 

SURVEY  OF  SEMI-AUTOMATED  FORCES  BRIEFING 
(MITRE  CORPORATION) 
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Recommended  SAFOR  Research  Areas 
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Recommended  SAFOR  Research  Areas 


Notional  View  of  Objective  SAFOR  System 


PIS  Protocol  (over  local  or  DSI  network' 


Features  of  Objective  System 
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A  Modular  Solution 
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Distributed  Interactive  Simulation 


Data  Analysis  |  p,an  View  DisPlay  Command  Post  Simulators 
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SAF  Applications 
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Simulations:  BBS,  AWSIM 
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ModSAF  Objectives 
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models,  platforms,  and  weapons 

V  Interface  A  block  for  other  DIS  simulations:  generic  physical,  task,  and 

mission  interfaces 

V  Protocols  DIS,  S1MNET 

V  Hardware  SGI,  MIPS,  Sun 


ModSAF  1 .0  Objectives 
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Controllability  W  Data 


ModSAF  Network  Architecture 
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Preview 

provides  perspective  view 


ModSAF  Software  Architecture 
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Public  &  Private  Headers 
Test  &  Example  Routine 
Documentation 
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Persistent  Obiects 
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Missions  Are  represented  by  a  network  of  task  frames 

Overlays  Organize  persistent  objects  representing — orders  of  battle, 

intelligence  information,  missions 

H-Hour  Used  to  synchronize  mission  execution  by  different  units 


Persistent  Object  Relationships 
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Architectural  Support  I  Terrain,  Network,  Control,  Utilities,  Graphics 
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olding  Area  for  Assigned  Tasks 


Task 


!. 


M 

C/3 

c3 

H 

<D 

-M 

o 

<D 

X 

W 

X5 

£ 

8 

a 


vm 

o 

co 

cm 

O 

>> 

U  *S 
o>  o 

-2  « 

2  ^ 

3  ^ 

^  Cm 

4  *Z5 

1  § 

O  i— i 


3 

o 


P* 

03 

CS 

•  »-4 

C/3 

03 

H 

03 

5-4 

«s 

£2 

<D 
■+— > 

<D 


2 
Ph 
S5  W) 

4)  -S  C 

*a.2 

a  m 

I  &§ 
soS 

Ph  . 


O) 

5$ 


D-27 


-  Used  by  Software  Model  at  Runtime  to  Reflect 
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sk  Frame  Stack 
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Task  Manager 
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Assemble  List  of  Tasks  to  Execute 

-  Sort  Execution  List 

-  Compare  List  to  Last  Tick,  Suspend  Missing  Tasks 

-  Execute  Tasks  In-order 


ModSAF  C2  Implementation 
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-  Mutual,  Context  Free,  Context  Rich 

-  Pull-based  Information  Flow 

User  Interface  in  Terms  of  Tasks,  Task  Frames 

-  Automated  GUI  Generation 


Mission  Example 
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ROUTE 


ModSAF  Interfaces 
to  Physical  Models 
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Runtime 

This  Capability  can  be  used  to  Support  Variable 
Resolution  Simulation 


ModSAF  Terrain  Databases 
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ModSAF  Component  Terrain  Usage 
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Compact  Terrain  Database  (ctdb) 
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Jbitiicient  search  Algorithms  tor  Jbievation  lookup 
Intervisibility  Calculations 

Optimized  for  RISC  Processors 


Compact  Terrain  Database 
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Canopy 

Linear  (roads  and  rivers) 


Quadtree  Database 


Quadtree  Feature  Networks 
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Interfacing  ModSAF 
with  Other  Systems 
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through  PO  Database 


ModSAF  Versions 
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IFOR  Al  Based  SAFOR  Built  on  ModSAF 

Capable  of  Learning  and  Adapting 
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and  restart 

SAFsim  SAF  Simulator 
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APPENDIX  E 


COMPUTER  GENERATED  FORCES  BRIEFING 
(INSTITUTE  FOR  SIMULATION 
AND  TRAINING) 
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Standards,  databases,  and  CGF  software  for  Electronic  Warfare. 
N61339-91-C-0091  (ECP  to  DIS  Standards) 

Sponsor:  STRICOM;  COTR:  Williams;  PI:  Wood 
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/ST  CGF  Testbed  Components 


Used  by  CGF  Operator  to  command  the  CGF  entities 
Mouse  and  keyboard  input,  plan  view  display  output 
01  and  Simulator  communicate  via  main  network 
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Real  battlefields  have  dismounted  infantry;  SIMNET  doesn't. 
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Because  of  scarcity  and  lack  of  realism,  the  Dismounted  Infantry  Module 
(DIM)  does  not  meet  these  needs. 
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T"\ck1  1  A/f1!*?!  T"\1  f1  Q 

■  Basic  SAFDI  system  (August  1993). 

■  Enhanced  SAFDI  system  (February  1994). 


User  evaluation  of  SAFDI 
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Effective  evaluation  of  SAFDI  will  require  its  use  in  training-like  exercises. 


SAFDi  entities 
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Basic  SAFDI  capabilities 
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Basic  SAFD!  capabilities:  Combat 
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Basic  SAFDI  capabilities 
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Group  Commands 
Example:  Mounting 
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Attach  and  Follow 
DIM  leads  assault 


increases  speed  because  of 
eater  travel  distance 


Basic  SAFDI  capabilities:  Configuration  files 
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File  format  designed  to  be  easy-to-modify  by  site  support  personnel 
Parameter  values  are  completely  documented  in  the  SAFDI  Support  Manual 


Functionality  testing 
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Examples  of  difficult  functionality  tests 
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Network  load  capacity  testing 
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Additional  entities  on  other  exercise  IDs 

Non-SIMNET  traffic  on  network  (Internet  or  sendfile/getfile  utilities) 
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S/MNET  problems  related  to  SAFDI:  Manned  simulators 
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SAFDI  Delivery  and  Installation 


c 

© 


-a 

© 

*-> 

c 

3 

O 

E 

» 


m 

« 

o 

w 

o 

UL 


<D 


<D 

.O 


£ 

o. 

<u 

m 


o 

<D 

<D 

£ 


a 

o 


C/3 

<D 

rt  O 
*-i  cd  J-h  Q* 

^  9^  &  S 

>■  c3  Oh 

OUOw 


Mcn^-in 


a> 

Q 


E-29 


Evaluation  Scenarios 


co 

O 


QJ 

C 

2e: 

TJ 

<D  CO 

N 

tz 

OPQ 

OPQ 

ss: 

OCQ 

fe 

Ph  * 

OS 


*3<< 

CO  CO 

2  gz 

5  §« 

PQ  0)  OQ 

.«  s® 

-  V-H  IO 

<N  iG  <n 
A 

HCuo 


^  w 

<?< 

SSPh 

*5  CO 


X  X  X  ><  * 
VO  <N  CN  C"l 


*-«  «H 

o  o 

4-J  4— <  /«-N 

aj  I— I 

ggp 

.5 .5<* 

coco^ 

baagu 

S  S  3  S3  (j 

SSS 

o  S  5  *-'  pS 

<j  S  S  Q  co 

£5  x  x  x  >< 
oo  A-  oo  <N 


c  o 

O  5/3 
?3  o 


.  <D 

cs  b 

O  t£ 


b 

3  J? 

rj  <4— ( 
’tS  <D 

^  a 


a>  — 

52  ’S 


32 

SP 


co  *rt  . 

jjI'S 


I  * 

SJ 1<5 

co  d  ,  S  *r< 

eg  §p$.52S 

*  Io^ts 
s  Ggn-o  a 

s  .2  a,  a  a 

otsoai 

‘,_l s 

®  g  S  S  o 
S  “  o  8  K 


I— I  5/3 

S-S 


Z  M  «  23  -- 

^  CO  CO  Ph  Q 

<csOOS 


E-31 


Q 

<  oo 
00  w 


Pm  - 

04 


hQS 


tJ-  W 

<?< 
tiPU 
x$  oo 


X  X  X  X 
-h  <N  <N 


J-H  t-4 

o  o 

4-»  H->  s — s 

cd  cd  t— i 

1111 

00  00  23  co 

g  SfflU 
Sas«fflo 
g<  <g  «  B 

SSS  £2°^ 

o  wwq3  i  ^ 

ugs^ffiS 

«a<  §  §  Q  O  co 

E5  x  x  x  x  x 

p  00  -si-  OO  (N  <N 


Oh  O 

°f 

91 


CO  rj 

0>  C 
Sa  £ 
co 

cd  TO 
Oh  CO 
;>£! 
o  33 
t:  >> 

cd  X> 


>  »-H 

O  o 

r~|  Oh 

MA  CO 

£P  O 
g  cd 
O  H 


CO  H 

o  cd 
oo  P 

2  £ 


S'hh 

Sq 

&pu 

Sc 

O  OO 
Uc* 
CD 


E-32 


dismounted  assault;  they  clear  the  first  pass  of  T-72s,  BMPs,  and  OPFOR 
SAFDI  fireteams. 


Scenario  # 3 :  Take  Crash  Hill 
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Evaluators'  Comments  (from  a  draft  of  the  ^ valuation  Report) 

■  CAPT  William  Hessenius,  CO  A/1-29 

"...  SAFDI  greatly  increased  my  unit's  training.  It  expanded  the 
SIMNET  battlefield  and  allowed  myself  die  unit  commander  to  assess  my 
unit  in  areas  not  realized  before  in  SIMNET. "  (Emphasis  added.) 


Enhanced  SAFDI 
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■  parameterized  fireteam  makeup 

■  consider  fireteam  exhaustion  in  Ph 
System  stress  warnings 
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Demonstrate  the  feasibility  of  the  interoperability  of  simulations 
supporting  different  entity  granularities  and  different  time  scales. 
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■  J 


Integrated  Eagle/BDS-D 


Eagle  Simulation 

•  Corps/division  level  combat  model  developed  at  TRAC. 

•  Smallest  units  (maneuver  units):  battalion  and  company. 
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Integrated  Eagle/BDS-D 


Typical  Eagle/BDS-D  Scenario 


Integrated  Eagle/BDS-D 


riginal  Proof  of  Concept  Functionality 

-  Disaggregation  of  aggregate  units  into  vehicles  in  virtual  world. 

-  Reaggregation  of  virtual  vehicles  into  aggregate  unit. 
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Integrated  Eagle/BDS-D 


Integrated  Eagle/BDS-D  Phase  2 

•  Expanding  the  Interface 

(1)  Add  vehicle  types:  helicopters,  aircraft,  and  ground  vehicles. 
°  (2)  Track  Eagle  units  within  CGF  Testbed. 
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Polygonal  terrain 
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Reconnaissance  planning 
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effective,  and  much  easier,  than  analyzing  the  entire  piece  of  terrain. 


Project  summary 
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Overview  of  the  All-Points  algorithm 

1 .  Given  a  terrain  test  area,  identify  the  set  of  Important  Points  fo 
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Identifying  the  Important  Points 
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Reconnaissance  planning  experiment 
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Terrain  database: 
Location: 

Size: 

Contour  interval: 
Approximate  scale: 


SIMNET  Ft.  Knox 
FS055665 
3  km  x  3  km 
5  meters 
1:18000 


Figure  19.  Clear  terrain  test  area. 


Terrain  database:  SIMNET  Ft.  Knox 

Location:  ES845950 

Size:  3  Km  x  3  km 

Contour  interval:  10  meters 


Approximate  scale:  1:18000 


Figure  20.  Mixed  terrain  test  area 
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Terrain  Reasoning  for  Reconnaissance 
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All-Points'  route  on  the  Mixed  terrain  area 
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Experimental  data  and  analysis 
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Reconnaissance  planning  times 
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Route  completion  times 


Targets  sighted 


CLEAR  Test  Area:  Defensive  Layout  II 
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Statistical  comparison 

Populations:  overall  performance  of  the  reconnaissance  planners. 
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Statistical  comparison  (continued) 
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Reconnaissance  planning  times: 
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Summary  of  results  (continued) 
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The  All-Points  algorithm  performed  reconnaissance  planning  at  a  level 


CGF  C  TO  Ada  Conversion 


The  task 


Implement  a  CGF  Simulator,  written  in  Ada,  functionally 
equivalent  to  the  1ST  CGF  Testbed  Simulator  version  6.400. 


Goals 


Determine  whether  it  is  practical  to  write  CGF  systems  in  Ada. 

Determine  the  effects  of  Ada,  relative  to  C,  on  software 
engineering  quality  in  a  CGF  system. 


Determine  the  effects  of  Ada,  relative  to  C,  on  execution 
speed  in  a  CGF  system. 
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CGF  Testbed  as  of  January  1993 


CGF  has  evolved  to  a  reasonably  well  designed  product. 


Functions  are  hidden  (static)  as  far  as  practical. 


No  data  is  exported  (data  is  on  the  stack  or  static) . 


Modules  are  recognized  and  binding  of  all  types  is  minimized. 


Since  the  C  mechanism  for  data  hiding  is  "all  or  nothing" 
(being  file  based)  artificial  means  of  enforcing  weak  bindings 
are  used. 


The  CGF  Simulator  consists  of  approximately  58,000  lines  of  code 
(including  blanks  and  comments) ;  it  is  ANSI  c  compiled  with  using 
a  C++  compiler. 
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January  27,  1993 


Ada  Conversion  Strategy 


One  extreme  approach  is  to  do  a  C  to  Ada  translation.  The 
other  extreme  is  a  complete  redesign,  needed  because  Ada  offers  a 
whole  new  approach  to  software  engineering. 


Position  going  into  this  project: 


A  direct  translation  is  of  no  use. 

The  Ada  conversion  project  will  produce  an  Ada  product. 
There  is  no  intent  of  producing  C  written  in  Ada. 


A  re-design  is  not  necessary. 

Ada  supports  the  best  of  the  1980's  software  engineering 
techniques.  All  of  the  artificial  techniques  used  to 
enforce  cohesion,  data  hiding,  weak  binding,  etc.  can  be 
replaced  with  direct  Ada  support. 


The  C  version  of  the  Simulator  is  playing  the  role  of  the  Ada 
product's  design  document.  It  is  natural  to  think  it  would  also 
serve  as  pseudo-code,  and  to  an  extent  this  is  true,  but  the  Ada 
team  is  not  doing  a  simple  translation,  we  are  building  an  Ada 
product . 


January  27 ,  1993 


Risks 


No  project  with  such  great  scope  is  without  risk.  While  an 
outright  failure  is  not  expected,  many  problems  are  possible: 


If  the  Ada  team  attempts  to  over-refine  the  Simulator  during 
the  conversion,  the  project  will  take  too  long. 


The  assumption  that  Ada  tasks  can  replace  the  Simulator 
executive  may  not  be  valid.  The  Simulator  executive  was  built 
to  fill  its  role  exactly,  replacing  it  with  Ada's  general 
tasking  support  may  cause  a  variety  of  problems  (the  most 
obvious  being  performance  degradation) . 


The  Simulator  uses  some  facilities  which  may  prove  difficult 
to  adapt: 


•  High  memory  support  for  terrain  information  (this  should 
be  unnecessary  with  the  Ada  version) . 


•  Graphics  support. 


LAN  card  interfaces. 


April  27,  1993 


Expectations  versus  Reality 

The  quotes  are  from  the  slides  shown  in  January. 


"The  Ada  conversion  is  a  natural  continuation  of  the  C6F 
development. " 

The  conversion  is  more  revolutionary  than  evolutionary. 
More  fundamental  changes  are  being  made  than  had  been 
anticipated. 


"The  Ada  conversion  project  will  produce  an  Ada  product. 
There  is  no  intent  of  producing  C  written  in  Ada." 

This  is  the  golden  rule  for  the  Ada  team.  There  is 
nothing  that  would  give  away  this  project's  C  origins. 


"A  re-design  is  not  necessary.  ...  All  of  the  artificial 
techniques  used  [in  the  C  version]  to  enforce  cohesion,  data 
hiding,  weak  binding,  etc.  can  be  replaced  with  direct  Ada 
support. " 

The  latter  statement  is  true  without  reservation.  The 
former  is  more  troublesome.  Significant  parts  of  the 
system  have  been  re-designed. 


"The  use  of  Ada  tasking  should  make  it  possible  to  eliminate 
the  Simulator's  built  in  executive." 

Ada  tasking  has  become  the  centerpiece  of  the  new 
simulator. 


"The  Ada  design  and  run  time  checks  will  eliminate  the  need 
for  many  of  the  facilities  hand  coded  in  C...." 

This  is  largely  true. 


"If  the  Ada  team  attempts  to  over-refine  the  Simulator  during 
the  conversion,  the  project  will  take  too  long." 

We  are  making  tremendous  changes  in  the  system,  but  our 
progress  is  excellent. 
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April  27,  1993 

Performance  Issues 


Are  Ada  executables  inherently  slow? 

Even  Ada  team  members  are  concerned  about  the  Ada  version's 
performance.  Nonetheless,  we  do  not  second  guess  the  compiler 
by  choosing  an  implementation  technique  based  on  what  we 
believe  will  produce  tighter  code. 


Micro  versus  Macro  Efficiency 

-  The  C  simulator  does  low  level  optimizations  which  are  not 
practical  in  Ada. 

•  Micro-efficiency  is  less  important  than  macro  efficiency. 


•  The  same  algorithms  are  used  so  we  should  have  roughly 
the  same  macro-efficiency  and  the  better  Ada  organization 
may  increase  efficiency. 

•  Worries  about  constraint  checks  (as  unnecessary  code)  are 
probably  overblown. 

-  The  Protocol  code  may  pay  a  heavy  price  in  efficiency. 

•  The  C  version  was  designed  to  avoid  data  copying  by 
contaminating  the  simulator  with  some  protocol  design 
attributes . 

•  The  Ada  simulator  makes  no  compromises  and  so  it  will 
have  a  much  more  complex  application  protocol  layer. 

•  Lower  protocol  layers  may  have  to  do  data  copies. 


Faster  hardware  can  mitigate  efficiency  problems. 

•  Everything  about  the  Ada  environment  is  designed  to  make 
it  easier  for  people  to  design,  implement,  test, 
maintain,  and  enhance  software. 


•  Costs  for  faster  hardware  (if  necessary)  must  be  balanced 
against  the  cost  of  maintaining  and  upgrading  code 
written  in  a  more  primitive  language. 
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July  12,  1993 


Ada  Conversion  Project  Status 


Timetable  Changes 


The  Ada  conversion  team  expended  all  of  the  time  originally 
estimated  for  the  conversion  as  of,  approximately,  July  1, 
1993. 

The  new  estimated  completion  date  for  conversion  is 
December  31,  1993. 

Development  Problems 

Protected  Mode/Real  Mode  Interface 
Memory  Shortage 
Library  Sizes 
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July  12,  1993 

Code  Quality 


The  Ada  "team  makes  a  conscious  effort,  to  use  the  Ada 
facilities  most  likely  to  lead  to  the  highest  code  quality.  We 
continue  to  improve  code  quality  wherever  practical.  Examples: 


In  spite  of  our  efforts,  we  had  used  inappropriately  broad 
types  for  some  quantities.  There  was  only  one  speed  type, 
which  was  used  for  both  DI  and  missiles  ( ! )  .  We  now  have 
types  appropriate  for  the  individual  entities,  eliminating  the 
Mach  1  DI. 


In  looking  into  the  last  item,  we  recognized  a  whole  class  of 
data  and  types  which  were  over-generalized.  As  part  of 
changing  the  speed-type,  other  overly  general  structures  were 
eliminated. 


The  Ada-CGF  code  uses  generics  wherever  appropriate  to  share 
code.  In  spite  of  the  break  up  of  encompassing  data 
structures,  the  behavior  and  dynamics  code  remains  flexible 
because  it  is  instantiated  appropriately  for  the  entity  in 
question. 


It  may  be  worth  noting  that  changes,  such  as  noted  in  these 
examples,  have  often  lead  to  the  subjective,  but  comforting,  "ah- 
ha"  response.  4 

Consider  dynamics: 

Parts  of  dynamics  code  unique  to  a  vehicle  is  written  in 
the  package  for  the  vehicle. 

4 

Parts  to  be  shared  but  which  are  dependent  on  the 
vehicle's  associated  data  types  is  generic. 

-  The  remaining  code  consists  of  procedures  which  interact 
with  vehicle  instances  through  parameters.  The  code  does 
not  need  to  accept  overly  general  data  structures,  nor  4 

does  it  have  to  ask  what  is  being  processed  ("am  I  a 
DI?")  by  examining  its  own  data. 


4 
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Lessons  Learned 


Using  Ada  on  Personal  Computers 


Insure  your  PC  is  up  to  the  task. 

We  expected  to  do  all  the  development  on  386  33  Mhz.  PCs  with 
less  than  4  megabytes  of  memory.  This  would  have  been 
impossible;  by  adding  memory  the  task  would  not  be  impossible, 
but  would  have  been  impractical.  Whether  a  task  is  practical 
on  a  given  machine  depends,  of  course,  on  the  task;  For  our 
task  486  machines  running  at  66  Mhz  with  4  megabytes  are 
inadequate;  with  additional  memory  we  should  be  able  to 
complete  the  project. 
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Using  Ada  for  CGF 


The  Ada  CGF  Software  is  of  higher  quality  then  the  C  rendition 

-  The  language  encourages  good  software  practices. 

-  The  enforcement  of  software  discipline  is  much  more 
powerful  than  most  people  realize. 

It  is  difficult  to  imagine  anyone  seriously  disputing  the 
Ada  team’s  claim  that  the  Ada  code  is  of  much  higher 
quality  than  the  C  version. 

Ada  Facilities  are  well  suited  for  simulations 

-  Ada  tasking  eliminates  the  need  to  build  custom 
executives. 

At  least  one  member  of  the  Ada  team  believes  the 
tasking  capability  alone  is  sufficient  reason  to 
make  Ada  the  language  of  choice  for  CGF. 

-  Generics  are  powerful  tools  for  customizing  tasks  for 
various  entities. 

A  significant  amount  of  code  can  be  shared  by  DIs 
and  tanks  in  spite  of  their  obvious  differences. 
Thanks  to  generics,  the  code  takes  on  the 
appropriate  characteristics  for  the  entity. 

• 

-  Ada  support  code  (such  as  constraint  checks)  finds  errors 
that  would  otherwise  be  missed. 

The  Ada  team  has  found  places  in  the  C  code  where 
uninitialized  memory  is  used  for  floating  point 
values.  In  most  cases  the  nature  of  the  arithmetic 
done  with  this  memory  allows  the  simulation  to 
continue,  but  this  is  a  time  bomb.  Ada  trapped  the 
error  immediately. 
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Intelligent  Simulated  Forces 
C6F  Ada  Conversion  Experiment  Status 


Over  58,000  lines  of  tested  Ada  code  have  been 
written. 

This  is  up  from  35,000  lines  at  the  last  quarterly  review.  To 
completely  represent  the  6.4  C  version  will  probably  take 
about  70,000  lines  of  code. 


External  data  and  events  (files  and  keyboard)  are 
correctly  used  in  almost  all  cases. 


Most  of  the  protocol  code  is  complete. 


About  a  month  ago  our  consultant  was  able  to  solve  the 
protected/ real  mode  problem.  After  some  rapid  perturbations 
a  usable,  though  limited,  version  of  a  packet  driver  interface 
was  delivered,  and  has  been  in  use  ever  since. 

Our  consultant  has  recently  developed  a  more  robust  and 
complete  version  of  the  driver  support  which  has  yet  to  be 
integrated . 

Most  of  the  higher  layer  protocol  support  is  in  place. 


Vehicle  dynamics  are  complete. 

The  bulk  of  the  behavior  code  has  been  developed. 
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The  FSM  Architecture 

The  FSM  design  is  fundamental  to  intelligent  behavior,  and  yet 
the  FSM  implementation  is  radically  different  in  the  Ada  and  C 
versions  of  the  Testbed.  Many  key  questions  raised  in  discussing 
conversions  to  Ada  were  addressed  when  designing  the  FSM  support. 

Here  are  some  of  the  key  features  required  by  t>  ^SM 
implementation  and  how  they  are  handled  by  the  two  systems 


FSMs  are  tasks 

FSMs  must  be  able  to  receive  messages  and  act  on  them.  For 
example,  an  FSM  may  need  to  be  awakened  when  another  FSM 
completes  or  when  a  timer  expires. 

C:  All  tasking  is  done  through  a  custom  executive. 

"Ordinary"  (non-FSM)  tasks  have  control  blocks  (for  their 
data) .  FSMs,  and  their  associated  data,  are  accessed 
through  the  control  block  of  their  parent.  Messages  for 
FSMs  are  delivered  by  locating  the  parent  task  and  then 
locating  the  FSM. 

Ada:  FSMs  are  subtasks  of  the  entity  which  invoked  them. 
Messages  for  FSMs  are  delivered  to  the  parent  which  then 
delivers  the  message  to  the  FSM. 

In  many  ways  there  is  a  good  parallel  between  the  two  versions 
in  this  mechanism.  The  key  difference  is  that  the  Ada  version 
uses  the  Ada  features  to  maintain  the  tasks. 

FSMs  modify  the  data  of  their  parent  task 

For  example,  when  a  vehicle  uses  an  FSM  to  turn,  the  FSM  must 
periodically  adjust  the  vehicle's  yaw  so  the  vehicle  will  turn 
gradually. 

C:  The  FSM  is  given  a  pointer  to  the  parent  task's  control 

block.  This  is  practical  since  tasks  in  the  C  system  all 
have  control  blocks.  Because  the  FSM  can  directly  access 
the  vehicle's  control  block  it  has  access  to  all  of  the 
vehicle's  data. 

Ada:  There  are  no  control  blocks  in  the  Ada  implementation. 
The  vehicles  (ACTORs)  are  tasks  which  have  ordinary  local 
data.  FSMs  are  generic  and  are  instantiated  with  OUT 
parameters  for  data  which  the  FSM  must  modify.  The  FSM 
is  given  access  only  to  data  which  it  needs. 
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FSMs  retain  state  information  from  event  to  event 

State  machines  run  through  a  sequence  of  states;  events  are 
interpreted  in  the  context  of  the  FSM's  active  state. 

C;  An  FSM's  state  is  represented  by  a  function.  When  an  FSM 
is  activated  to  process  an  event  its  current  state  is 
called  with  an  indication  of  the  event  as  well  as  a  data 
structure  which  serves  as  a  control  block  for  the  FSM 
(its  data  area) . 

Ada;  FSMs  are  implemented  as  tasks.  Since  they  are  tasks  they 
retain  their  local  data  without  special  mechanisms.  A 
local  enumeration  is  used  to  track  the  current  state.  A 
switch  on  the  current-state  variable  yields  the  proper 
context . 

FSMs  must  be  able  to  report  results  to  other 
entities 

If  a  vehicle  wishes  to  fire  a  weapon,  the  FSMs  used  to  do  this 
will  ultimately  activate  an  FSM  to  aim  the  weapon  before  it  is 
fired.  When  the  aiming  is  complete  the  parent  needs  to  be 
informed  so  firing  can  commence. 

C;  a  general  purpose  FSM  reply  mechanism  is  implemented. 
The  list  of  possible  replies  is  set  out  as  an  enumerated 
type  used  by  all  FSMs.  Along  with  "SUCCESS,"  replies 
exist  to  cover  various  anticipated  scenarios  (e.g., 
"IMPOSSIBLE"  and  " EXTENDED  JROUTE_NEEDED") . 

Ada;  A  general  reply  mechanism  is  defined.  The  FSMs,  as 
ordinary  tasks,  define  replies  just  as  ordinary  ACTORs 
do.  The  possible  replies  are  defined  by  the  task  sending 
the  reply  (in  its  specification) .  This  way,  only  replies 
that  make  sense  for  the  task  under  consideration  are 
defined,  and  as  much  data  as  makes  sense  can  be 
associated  with  the  reply.  Hypothetically,  AIM  could 
tell  its  parent  it  is  aimed  and  the  direction  of  the 
target  or,  in  case  of  failure,  exactly  why  it  failed 
(perhaps  the  target  was  no  longer  visible) . 
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FSM  re-use  may  require  associated  FSMs  to  be 
terminated 

If  a  vehicle  is  told  to  route  to  a  point  it  will  invoke  a 
series  of  FSMs  to  carry  out  this  behavior.  These  FSMs  may 
invoke  an  FSM  to  cause  it  to  face  the  appropriate  direction. 
Should  some  other  behavior  request  the  vehicle  to  face  another 
direction,  there  is  a  clash  between  the  requests.  This  is 
resolved  by  giving  the  new  request  priority,  which  forces  the 
route  to  be  abandoned.  In  so  doing,  the  various  routing  FSMs 
are  all  shut  down. 

C:  a  series  of  functions  is  used  to  recursively  kill  FSMs  by 

removing  them  from  the  list  of  active  FSMs  for  an  entity. 
The  mechanics  of  this  implementation  prevents  2  copies  of 
an  FSM  from  running  at  the  same  time  (a  vehicle  with  two 
weapons  cannot  aim  them  at  the  same  time  if  they  share 
any  FSM  to  accomplish  aiming;  vehicles  cannot  launch  two 
missiles  at  the  same  time  because  missiles  rely  on  FSMs)  . 

Ada:  Entities  which  use  FSMs  have  a  subordinate  task  which 
tracks  which  FSMs  are  active  and  who  started  them. 
Associated  data  determines  how  many  copies  of  an  FSM  can 
run  at  once.  Starting  new  FSMs  will,  when  appropriate, 
bring  down  the  necessary  FSM  subtree. 

Recovery  of  dynamically  allocated  memory  has  made  FSM 
shutdown  complex  in  the  Ada  version  which,  in  turn,  has 
complicated  the  FSM  hierarchy  control. 
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Miscellaneous 


Compilation  Time 


System  compilation  time  is  about  2  hours  for  a  full  build 
(58,000  lines,  229  files)  .  Large  disk  caches  are  used  (on  the 
order  of  16  Megabytes)  during  compilation;  this  is  essential 
to  keep  compilation  time  down. 


Library  Sizes 


Our  system  is  configured  across  4  libraries,  ranging  in  size 
from  21  Megabytes  (the  main  development  library)  down  to  1/2 
Megabyte  (for  the  protocol  library);  the  total  size  is  about 
27  Megabytes. 


October  13,  1993 


Cone! us  ions 


The  Ada  CGF  Testbed  has  developed  to  the  point  that  some 
preliminary  conclusions  can  be  made.  These  conclusions  have  not 
been  quantified  but  are  opinions. 


CGF  systems  can  be  written  in  Ada 

The  Ada  CGF  Testbed  is  already  sufficient  to  demonstrate  this. 


Ada's  software  engineering  features  can  be  used 
to  produce  higher  quality  code. 

-  strong  type  checks  not  only  catch  errors,  they  encourage 
proper  typing  (our  tanks  are  not  capable  of  speeds  as  great  as 
a  missile's)  and  can  simplify  code. 

-  Packages  encourage  strong  encapsulation  and  localization. 
By  being  careful  the  Ada  team  has  kept  the  complexity  of 
package  specifications  to  a  minimum,  avoiding  unnecessary 
binding.  Ada  makes  people  think  about  these  issues. 

-  Generics  encourage  code  re-use  and,  simultaneously, 
customization . 
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Future  production  CGF  systems  should  be  done  in 
Ada 


Production  products  should  be  given  the  benefit  of  Ada's 
ma inta inab i 1 i t y . 


i  Converting  an  existing  system  from  C  to  Ada 

should  be  approached  as  a  redesign,  not  a 
"translation" 


ft  Without  this  approach  the  benefits  of  Ada  will  not  be 

realized.  Attempts  to  preserve  aspects  of  the  C  CGF  Testbed 
proved  counterproductive . 


Should  Ada  be  used  for  research? 


There  is  a  big  difference  between  exploratory  programming  and 
production  programming.  Most  people  we  have  asked  will  agree 
that  Ada  is  the  right  choice  for  production  programs.  Whether 
Ada  is  the  right  choice  for  research  has  yet  to  be  answered. 
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October  25,  1993 

Intelligent  Simulated  Forces 
CGF  Ada  Conversion  Experiment 


Preliminary  Performance  Evaluation 
October  25,  1993 


Part  of  the  Ada  team's  resources  were  redirected  to  carry  out 
a  performance  evaluation  of  the  existing  Ada  CGF  Testbed.  This  was 
done  on  October  20,  21,  and  22. 


The  Evaluation  Parameters 

Three  dimensions  of  the  CGF  Simulator's  performance  were 
considered  for  evaluation. 

•  The  number  of  vehicles  that  can  operate  locally  (i.e.  on 
a  single  copy  of  the  Simulator) . 

•  The  number  of  remote  vehicles  which  can  be  serviced. 

•  Robustness  under  internal  computational  load. 

The  third  item  refers  to  observation  of  the  Simulator 
performance  as  the  number  of  internal  computations  is  varied. 
This  was  accomplished  by  varying  the  frequency  of  Line  Of 
Sight  (LOS)  computations,  an  expensive  process. 


Recognition  of  Simulator  Stress 

A  Simulator  under  stress  may  fail  in  a  number  of  ways, 
including: 

•  A  breakdown  in  behavior. 

•  A  system  crash. 

•  The  loss  of  incoming  traffic  (dropped  packets) . 


E-96 


October  25,  1993 


Custom  Testing  Tools 

To  gain  maximum  control  over  the  variables  in  the  tests,  and 
to  simplify  the  effort,  a  program  was  built  which  transmits  a 
valid  appearance  packet  at  a  user  selected  rate  (up  to  425 
packets  a  second) . 

Increasing  the  rate  of  transmission  effectively  loads  the 
system  under  test  with  network  traffic,  but  this  is  not  the 
same  as  increasing  the  number  of  vehicles  because  the  packets 
all  represent  the  same  vehicle  at  the  same  location. 

For  the  purposes  of  discussion,  each  5  packets  per  second  is 
said  to  represent  a  "pseudo-vehicle."  Idle  remote  vehicles 
produce  a  packet  every  5  seconds,  moving  vehicles  produce  less 
than  7  packets  a  second. 


Preliminary  Test  Adjustments 

All  tests  were  run  with  12  vehicles: 

•  This  decision  came  about  for  several  reasons,  the  key 
being  that  the  rated  capacity  of  the  C  Simulator  is  12. 
This  decision  also  simplified  the  testing  and  the 
presentation  of  results. 

The  error  threshold  must  have  at  least  two  dimensions: 

•  It  was  discovered  that  the  Ada  Simulator  dropped  packets 
even  under  mild  stress  and  so  our  tolerance  threshold  had 
to  have  a  "dropped  packet"  dimension. 

•  The  C  Simulator  was  never  seen  to  drop  packets,  so  a 
visual  threshold  was  established.  If  a  routing  vehicle 
missed  points  the  Simulator  was  viewed  as  past  the 
tolerance  threshold.  The  Ada  Simulator  also  shows  this 
form  of  stress. 

Test  Summary 

A  script  was  run  which  generated  11  turning  vehicles  and 
another  vehicle  following  a  reasonable  complex  route.  A  LOS  rate 
was  established  and  the  packet  load  was  varied  to  locate  the 
threshold  for  each  Simulator.  The  results  are  summarized  in  the 
following  tables  and  then  graphically. 


Evaluation  Results  for  the  C  Simulator 


LOS 

packets/sec 
( ps-vehicles) 

%  discarded 

visual 

degradation 

120 

225  (45) 

0% 

no 

• 

ISO 

225  (45) 

0% 

yes 

150 

160(32) 

0% 

no 

• 

171 

225  (45) 

0% 

yes 

171 

160  (32) 

0% 

no 

• 

200 

225  (45) 

0% 

yes 

200 

160  (32) 

0% 

no 

240 

225  (45) 

0% 

yes 

• 

240 

160(32) 

0% 

yes 

240 

131  (28) 

0% 

no 

300 

160 (32) 

0% 

yes 

• 

300 

131 (28) 

0% 

yes 

300 

97  ( 19) 

0% 

no 

400 

160(32) 

0% 

yes 

• 

400 

131(28) 

0% 

yes 

400 

97(19) 

0% 

no 

500 

36(7) 

5% 

yes 

• 

500 

38  (7) 

5% 

yes 

500 

40(8) 

5% 

no 

LOS:  Number  of  LOS  computations  done  per  minute, 

packets/  sec:  Number  of  packets  received  per  second. 

The  parenthetical  number  indicates  the  number  of  pseudo¬ 
vehicles. 

Visual  Deg.:  Was  visual  degradation  noticed? 
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Evaluation  Results  for  the  Ada  Simulator 


LOS 

packets/sec 
( ps-vehicles) 

%  discarded 

visual 

degradation 

60 

160(32) 

>50% 

no 

• 

60 

131 (28) 

-  10% 

no 

60 

97  (19) 

<  10% 

no 

67 

131 (28) 

>  10% 

no 

• 

67 

97  (19) 

-  10% 

no 

67 

82  (16) 

<  10% 

no 

75 

131 (28) 

>  10% 

no 

• 

75 

97  (19) 

~  10% 

no 

75 

82(16) 

<  10% 

no 

86 

97(19) 

>  10% 

no 

• 

86 

82(16) 

~  10% 

no 

86 

74(15) 

<  10% 

no 

100 

66  (13) 

>10% 

no 

• 

100 

51  (10) 

~  10% 

no 

100 

46(9) 

<  10% 

no 

120 

66(13) 

>10% 

no 

• 

120 

51  (10) 

~  10% 

no 

120 

46(9) 

<  10% 

no 

150 

24(5) 

>  10  % 

no 

• 

150 

22(4) 

~  10% 

no 

150 

20(4) 

<  10% 

no 

LOS:  Number  of  LOS  computations  done  per  minute, 

packets/  sec:  Number  of  packets  received  per  second. 

The  parenthetical  number  indicates  the  number  of  pseudo¬ 
vehicles. 

Visual  Deg.:  Was  visual  degradation  noticed? 
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C  and  Ada  Performance  Thresholds 


LOS  Checks  per  minute  (Internal  Load) 


October  25,  1993 

Conclusions 


The  Ada  version  is  slower. 

Possible  Reasons  for  the  slower  execution 
include: 

The  Ada  version  is  a  new  product.  The  C  version  is  a 
mature  product  and  has  undergone  continuous  improvement  often 
aimed  at  enhanced  efficiency. 

-  The  Ada  packet  support  is  in  the  form  of  a  TSR  standing 
between  the  Ada  Simulator  and  a  packet  driver.  This  code  is 
very  new  and  may  contain  serious  problems.  Architectural 
problems  on  the  PC  may  be  causing  us  problems. 

This  cannot  be  the  complete  problem,  however,  since  the  Ada 
Simulator  can  be  stressed  without  any  traffic  (and  as  few  as 
4  vehicles) . 

-  The  Ada  team  has  made  no  compromises  for  efficiency.  All 
checking  is  on  (except  in  one  checksum  routine  where  integers 
are  intended  to  overflow) ,  tasks  are  used  to  protect  critical 
sections,  and  there  are  no  mixed  language  sections  (the  TSR, 
which  is  written  in  C,  is  not  bound  with  the  Ada  program;  it 
is  simply  a  gateway  to  the  packet  driver) . 

System  profiles  may  uncover  some  expensive  areas. 

-  The  Alsys  compiler,  and  PC-Ada  compilers  in  general,  are 
not  as  mature  as  C  compilers. 


Can  the  Ada  Simulator  be  improved? 

Of  course.  It  is  an  open  question  as  to  how  much  it  can  be 
improved.  If  it  turns  out  the  TSR  is  causing  problems,  we  can 
hope  for  major  gains  without  compromising  the  design. 

It  would  be  a  mistake  to  optimize  the  Ada  Simulator  by 
compromising  the  software  engineering  quality  of  the  product. 
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AUTOMATED  FORCES  TECHNOLOGY  PROGRAM  BRIEFING 
(ADVANCED  RESEARCH  PROJECTS  AGENCY) 
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Technology  Today  •  Selected  Vehicles  and  platform  entities 

•  This  program  will  address 
the  technology  to  fill  this  gap 
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Systems  (Air  Force) 

Representation  of  systems  of  systems  and 
EW  in  DIS  (Navy) 
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»  Subject  to  battlefield  effects 

-  Approach  will  extend  DIS  broadcast  and  throw  away  paradigm 
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Level  0  Concept  Development  and 
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Level  1  Proof-of-Concept  Development 
Ground  Operations:  FY94-97 
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Q  oc 

n§ 


ss> 

15 

c  o 
Oh 
±-C/> 

S  S 

2  J= 

S| 

=  m 
*i  o) 

>*£ 
o>c 
°  — 

o  o 
c  *- 

o  O 

#  o 

O  c 

LL  O 

<o 


f? 

c  c 

5 ’5 

'S'D 

IS 

0)0 

li 

II 


St 

11 

ig. 

f  8 

oO 

2S 

S  5 
Se 

C  (0 

§  o> 

II 

£*  O 

(0  © 
©  C 


o>  * 
>-  ° 
U.  © 

O  | 

1  • 
III 


§  o 
x  £ 


Is 

c 

O  CD  = 

33  C  -O 
SO® 

J5  O  O 
«  o  jc 

o  «  c 

i  §  ® 

■8  Eg© 

4-»  O  fl)"> 

c  S- c  § 
o  8  8  8 

2.  o  as 
o  o  3  o> 

o  o  =  g 
o  4  30 

C  O^h 

Q-  ot:o5 
«  Q-g.’g 

5=  >>a» 
10  ?go 
a  S  ®  ft 
>-  o  o  g 

Z  IS  a 

O  O  a  a 

C  (rs  O 

w  §S  & 

i  t  ©  3 

<  a  © 


Advanced  Research  Projects  Agency 


APPENDIX  G 


SAF  CONCURRENT  ENGINEERING  TEAM  BRIEFING 

(IBM  CORPORATION) 


G-l 


SAF  Peer  Review 


G-3 


G-4 


28,1993 


Close  Combat  Tactical  Trainer 


October  28, 1993 


PROGRAMS 


JMtMVI/ ArilVMT  •  •  •  • 

Integrated  Development  Team  CIOSG  Combst  TaCtiCfll  TrsiflGf 


G-7 


CONTROL 


w 

I 

5 


G-9 


0 

0 1 


s< 

Sco 


>o 

Err 

sh£ 


<  C 
CO  « 


■f 

£l 

«s 

gUI 

E 

0) 


r»  05  52 

See 

«  s  3 

©  w  « 

■n  >,  > 

o  CO  CO 

IE  CD  co 

^  CO  CM 


•—  I 

m  3 


O  £ 


■5  Cl  O 
?  3  LL 
®  J  DL 

|  6S  O 

=  •  • 


«  1§ 

m  < 

co 
co  B 

10  _* 

I  co 
x> 

JO 

O  0- 
CO  -o 


0 

•M  o 
o  ^ 

1  I 

8  DC 

H  o 
0  ^ 
©  -I 

E  m 

•3  • 


4r  ® 

O  F 


0 

W  2 

O  § 

Q)  ^ 
Q.  < 
W  © 

<  O 
C  CO 

.2  00 

IS 


agi1 

8 

S  liJ  a 
LU  _  o 

©go 

O)  .2 

©  to  0 

E-52  a? 
nj  4* 

CO  o  © 
O  JO 


•  • 


G-10 


Command  From  Simulator 


Requirements  |  CCTT  SAF 

CODE 


1° 

I* 

s 

.© 


X 

o> 

CB 

„3 

< 


• 

CO 

0) 

o 

ffl  k 

O  4?  © 

©  I  ^ 

2T  "  cb 

o  ES 


go  o  » 

flgjc  g 

©  10  m  P 


«  .  *g  £So  ®fS®E  1X1 

^o2®-*#  t-Q  iS^I®  © 

S  Z  O  r  O  r  O  r  ©  Q.  <i>  >  •—  t; 

c  3  8  ~§  *g  «  .SL  Q  gf  ola  2 

2  8  off  Eo  O  8  a.E£  §22 


E  M 

m  ,i  * 

■=  S  -o 

g|8* 

o 

>°  jo 

=  ©  q 
*■»  o  g 
C  m  -O 
©  ft  w 

_ 5  CO  LU 


© 

c 

© 

©  E 

12 

^  §■ 
o  © 
co  a: 


T3 

^  c 
2  ©  w 
fl£ri 
©  S-lS 

©  CO  o  g.s  J= 


s  c  loco 

CO  (0  Ox)  3  O 


© 

© 

E 

3 

3 

© 

O 

o 

O 

>» 

o 

o 

o 

© 

UL 

F 

a 

G-12 

28,1993 


28,1993 


28,1993 


UJ  (0 

sE 
3  2 


§2 

aso. 

St 


a  o 

to  *“ 

<D  © 


>  CO 
2  c 
a  ® 

M  X 


c 

m 

©ll 

©< 

Q.C0 

©  t 

ES 

o  c 

"D  ? 

g>J2 

■°  6 
O)**- 

©  > 
-°S 

—  O) 

<  c 


c  © 

O)  o 

W 

3  « 

js  s 

^  ~  > 

o®  s 

c  o  a. 


>%  o 

.ts  c 

15*2 

:©  ^ 
>  © 
©  c: 

S° 

Q.C 

0.0 

3 ‘-5 
©  © 


c  >* 

3  := 

T3  ^ 
©  © 
©  © 
©  o 
-Q  © 

if 

*n  3 

^  N 


©  O  p  N 

roo.S  = 


§  3 

?.= 

iS-o 

®  = 
k_  © 


©  O 

"E § 

o- 

©  0 


C0£= 

£8. 

O  §- 

o  © 


$  8  Q.r 

|§  g5 

©  c  0 
111.1 
el  SS 

b ®  Ss 

B  75  ”  <2 

■—  i-*  ©  C 

-{=:-=  .±:  © 
£>  o  c  © 

<£  il  E 


p  o  © 

n  ©  *ts 

O  -*=5  © 


©  © 

©  >» 
fj  ■*— •  © 

111 

5  B.  i2 

^  o  = 

©  ©  9 
_c  >  © 

© 

w  ■©  © 

Ell  3 
S<  £ 
«co  f 

©  h-  0 

>h  % 

00  3 

©O  T3 
O)  c 
_©  ©  CO 

■of 

«  0  c  .9 

f.i 

a.  ©  o  s 
.£■5  ©o 


2% 

<3 


si 
2  ® 

.9  E 

■*—  k_ 

©  o 

©T> 

S-© 
o  w 

ol 

O  x 
O  © 
<<  »- 


w  O) 
©  c 

©  *c 

5  « 
f  ^ 

■0  « 

S  ® 

W  TJ 

©  c 

s « 

O  >s 
© 

c  5 


0S< 


o 

jo  ° 

Q_  O) 

s| 

o  3 

75® 

80 

§* 

•  «Mb 

o  5 

2  © 

CL 

©  © 
c  o 

Z>  © 

©  c 

-9  '© 

£Z  +-* 

o  2 
o  — 

©.a  0 
fc  ©  o 

o  §s 

o  ~ 

^  ©  T3 
-£*>  C 

©~  © 
C  3  Q_ 

’E  ©o 

o  ©rn 
o  *0 
"O  =  *2 

O  ®3 

9  Jl 

®  o  2 

©  O 

yrt  rn  u. 


£661*82 


G-16 


CCTT  SAF  Provides  the  R&D  Community  with  a  stable  Object  Oriented  Design 
and  Engineered  Code  baseline  using  Accredited  Tactics  and  Models 


G-17 


October  28, 1993 


ri 

?I 


<o 

Ij 

UL  C 

i:  o 
1 1 
Jf 

5- 

£u. 

■gw 

3t 

«5 

on 

■o  w 

(Q 


O  o 

0 £ 
®  E 


© 

©  c 

Q  = 
>  © 
*^S  © 

©  © 

E  « 

© 


C  LL 
©  < 
X  CO 
LLI  T5 

53 

<  1 
CO  C 
"O  © 
O  * 

IE  UJ 

©  © 
©  © 
3  3 
©  © 
DC  DC 


c 

<  E 

CO  © 

*S  3 

o  CO 

IE  « 

■f  0 

©  2 
©  M- 

c  O 

5>  w 
c  © 

0  -c 
©  o 
DC  D> 
© 


_© 

3 

T3 

©  *- 
_C  © 

o  o 

CO  O 


t= 

o  § 

0  o 

©  5 
2  £ 

o  e 

M  § 

_Q  © 

<  j| 

0  O 
O  CO 

I  2 
i  § 

€  Tjj 

a.  1 


i 

g»  § 

k.  ’-S3 

CL  © 


t  10 

I—  0 

£  -g  <  b 
3  ro  “  4c 

O  T5  3  ^ 
©  C  O  *o 

t;  ©  £  c 

|  55  g>  ® 
<  ?2| 
2  'Sj  h  ffl 

g  ®  >.2 

§  .9  =  ro 
o  o)  5  > 

2  iS  S2  c 

E  0  ©  -9 

g  0  x  © 
§  >  LLI  .9 
2  "c 

r  co  1  > 


28,1993 


fl 

k 


i  i 


T3  X 
Cy  VI 

|4  ~ 


CO 

■Q 

E 
•  o 

o 


•o 


o 

CO 

UJ(0 

■a  'Z 

3  0> 
coS 
30 

>2 

LU  g 

>»> 
*o  ® 
DW 

5)  0) 

<0.E 
*2  co 
2  o) 


b* 

Pm 


c 
0  O 


—  _  u 

sS; 

—  o  ® 
0  C  (0 
0  CL  3 

0  CL  0 

co<  cc 


G-19 


0  < 
It 

so 

LU  O 


“O  *o 
0  £ 

"O  0 

12 

x  . 

LU  U-  </> 

8§1 

0  O  ^ 

cr  See 


_  « 
T5  CU 
C  r-\ 
0  LJ 

*29 

cM 

?|6 
0^0 
(D  O  4= 

cess 


October  28, 1993 


Ut 

1:8  i 


2 

.1 

o 


•o 


c 

o 

£  3 

H  o 

T3  ® 
CP  Q 


^  a 

2 

3  *C 
O  o 

^  a 

2  3 

o  co 


<  jO 
U-  ~ 


o  C 

—  o> 
®  '55 


7*r  C/5  d) 

$2  iS  Q 

GQ 


f="l2 

o  f  I 

v—  —  'C 

O  3?  O 

*♦-  o  ^ 

fss 

*|3 

CD  O  © 
n  *n 
3  CT 

ts  8  § 

<d  a  £ 

.t=:  J=  Q_ 


•  • 


3 

•M 

CO  o 


■§  w  o 


E  S  -D  E  g 

£  55  «  5  a 


S  CO 

a  e 

CO  ^ 

-I 

c  o> 


O  iS  -  O  3  ~  O 

_  o)  oj  ^  o)  £  c  a 

■|  <  Q  ■%  <  05  co  il  < 
t  ^  «0 

iSS  •  •  £  •  •  i®  • 


G-21 


By  Building  On  A  Legacy  Foundation  We  Avoid  Reinventing  the  Wheel  and  Potential  False  Starts 


o 

c 

Z  c 

^  (8 

u.E 

<  e 

(0  g 

■o  c 

O  C 


o  § 

CO  g> 

OIL 
>< 
•55  co 

et= 

coO 

So 

® 

E 

q> 


£  S 

3  0 

o  -g 
q  iS 
-ts  co 

o  Q 

<  C 

ll 

<  ^ 

CO  O 

h= 

L_  JD 

o  O 

o  z 

o  5 

®  co  M 

u-  »  e 
<00 
CO  CO  o. 
"O 

€  •  • 


0 

0 

i_  0 

0  -Q 

g>  £ 

{5  0 

5  Q 


2 

0  fc 
0  0 
F  F 


•  • 


CO  F 
■o 


CO  F 
~o 


G-22 


28,1993 


m 

o 


o 

•jg 


.q 

i»l 

o 


$ 

o 


E 

tf 

i£ 


c 

<D 

E 

Q. 

O 

t 

a> 

Q 


1 


2 

a> 

m 


© 

CL 

O 


2 

c 


c-  Ji 

5  •§ 

■o  5 

o  ^ 

5  o> 


■o 

© 


(0 

T5 


CO 


O 

a. 

*o 

mmmm 

Q. 

CO 

DC 

o 

OS 

CC 


T3 

CD 

CD 


0} 

QC 


j§ 


© 


w* 

3 

© 

QC 


w  =2 
i  CD  C 
_  0 

2  E 

*a  © 

m  .is 

©  3 

3  5  cr 
"»  cr© 
«  ©  CC 
o  CC 


<0 

>»  > 

1  E 

©  © 


o 

c 


_  CD 
3  >* 
o  CO 
O) 


o 

c 


LL 
©< 
CD  CO 

It 

OO 

5o 


£ 

< 

_CD 

CD 

T3 

O 


C 

*c 

il 


c 

o 


O  -C 
0=  £ 
UJ  q 
«-  O 


g2 

S  Q. 
c  E 
.2*0 
COO 


2 

cc 

Q 

Li. 

< 

CO 

“O 

o 


o 

3 

T5 

O 


CL 

CO 

CD 


o 

o 


Q 

CL 


c 

o 


O 


CO 


"D 

c 

CO 


© 

E 


t= 

o 

o 


a 

o 

O 


co  © 

O  © 

CD  CD 
CO  QC 
£  O 


CD 

0 

a 


o 

co 


8 

Tl 

2 

c 


a 

3= 

a 

CD 


CD  © 

O)  o 
•E  £ 

■Q  ^ 


CD 

*s 

co 

*o 

c 

© 

4-» 

CO 


CD 


< 

CO 


•  am 

o 

0 

E 

o> 

Q. 

c 

© 

O 

c 

3 

o> 

§ 

0 

c 

0 

•  mm* 

2 

o 

5 

o 

LU 

£ 

© 

'cS 

“D 

CO 

< 

%  W 

| 

< 

O 

m 

• 

• 

c 

© 

E 

Q. 

O 


§ 

© 

a 


■o 

0 


cr 

0 

DC 


0 

GQ 


CO 
O)  £ 


cO 

.go 

0  V- 

0  o 
OIL 

<  = 

o  LU 
2T3 

H-  C 

o  © 


2~ 

is 

o  o 
COO 


.2  0 
©  E 

>  3 
C  O 
0  O 
QQ 


I 


G-23 


28.1993 


The  Hybrid  Approach  is  the  Lowest  Risk  Alternative  for  CCTT  SAF  Development 
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The  CGF  Architecture  provides  a  modular,  reusable  baseline 
supporting  horizontal  and  vertical  extensibility. 
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This  provides  scalability  of  the  number  of  simulated  entitles  per  site,  reduced  single  point 
failures,  and  flexibility  In  allocation  of  computer  resources  to  exercises. 
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modular,  reusable  components. 
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f/j/s  approach  supports  extensibility  and  inclusion  of  additional 
algorithms  from  ModSAF  research. 
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The  use  of  Ada  directly  promotes  present  and  future  reusability, 
controlled  configurations,  and  life  cycle  maintainability. 
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Validated  CISs  Provide  Source  Documentation  for  Implemented  SAF  Behaviors  and 

Serve  as  Their  Design  Specifications 
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Close  Mapping  Between  English  Language  CISs  and  Code  Facilitates 
Strong  Software  Development  Practices 
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CCTT  SAF  Open  Architecture  Provides  Flexibility  in  Assembling  Code  Modules 

to  Fit  the  Needs  of  An  Exercise  or  Application 


SAF  Behaviors  Code  Captures  the  Nature  of  Tactical 
Reasoning  Above  the  Platform  Level 

SAF  software  developed  from  CISs  exhibits  doctrinally  correct  tactical 
behavior  that  is: 

•  Traceable  to  US  and  OPFOR  doctrinal  literature 
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SAF  Behaviors  Code  Maps  Closely  to  Tactical  Knowledge,  Facilitating 
Knowledge  Transfer  from  SMEs  to  Software  Developers 
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S^F  Code  can  be  Generalized  for  Reuse  of  Common  Behaviors  or 
Specialized  to  Achieve  Systems-Speclflc  Behaviors 
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The  CIS  Development  and  Implementation  Process  has  Allowed  SMEs 
to  Effectively  Transfer  Tactical  Knowledge  to  Software  Engineers 
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CCTT  SAF  Behaviors  Design  Facltitates  Integration  of  Operations  Orders , 

Ad  Hoc  Command  Overrides,  and  Reactions  to  Situational  Interrupts  In  a  Natural  Way 
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Lessons  Learned  from  the  SAF  Behaviors  Prototype  will  Drive  the 
Design  of  Tactical  Behaviors  Code 
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CCTT  SAF  Behaviors  Code  Provides  a  C2  Tactical  Umbrella  for  SAF  Platforms  Code  Resulting 
from  a  Rigorous,  Repeatable  Knowledge  Capture,  Transfer  and  Translation  Process 
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The  SAF  User  Interface  facilitates  the  preparation  of  military  overlays  and 
the  creation  of  exercise  scenario  libraries  thereby  allowing  exercise 
conditions  to  be  replicated  and  analyzed 


© 

o 

JD 

E 

>» 

CO 


X 

0) 


D 

GC  ^ 
O  w 

CL  ® 

O  IT 

g  <5  S 

I?  « 

g-  O  to 

&  §  § 

gsa 

£  0)  g 
$0  Q-  E 
o  O  ® 

Q.  c  ■*- 
O  CO  © 

>»  ©  CO 
CO  > 


z  <s 

o  = 


CO 

CD 

>J  © 

o1  5 

Jq  ® 
E  § 

w  >> 

£  °> 

O  2 

LL  #A 
CL 

o  5 

-O  E 

CD  >, 

O  © 

©  C 

©  o 

00  « 


E 

o 


©  ^ 
o  o 
c  0) 
©  **— 
3  O 
0*T5 


CD  ©  m 

g  8  § 

5  a  s 

g  £  » 

c5  w  E 
■o  -E  © 
S  -o  t* 

CO  =  ^ 

2  jg  .2 

2  «  i 

g.  8  5 

•=  'a  ° 
©  ©  © 
>  X  © 

O  UJ  D 


8 


G-65 


28,1993 


G-66 


October  28, 1993 


o  '<* 


mEy 


M 


'0' 


G-69 


?J 

(0  o 

Sc 

ll 

©  © 

21 
a  g 

05 


(0  c 

M  © 

ig 

<21 

fi 

S-S 

Si 

is 

g2 

iSfi 

£  5* 

©  o 

s  © 
s« 

5« 

IIJ  c 

S3 

3  © 

It  3 
<  © 
(0  e 

©“ 


*D 

*5  >* 
-Q  c 
-  © 
«  -Q 

“C 

5  © 

3  Ol 

©  2 
N  T3 

c  £ 

E>o 

°'§ 

%  ® 
o  w 

•P  0 
k.  03 

8? 
3  a> 

®  g 
■*■*  ® 
s  « 

5  © 

75  b 

03  T3 

k.  r 

2  <5 
1  « 
©  ©  t: 

>  -5-  © 

S  WO 


©  03 

©  C 

co  b 

J5  5 

~  © 

© 

©  .o' 

§  -o 

Q.  © 

E  2 

8  © 

©  © 

W  CD 

*2  >* 

8  8 
©  © 

*D  © 

mmmm  V# 

3  © 

© 

o  o 

•  m^m 

©  co 
©  ^ 

|  8J2 

3  ©  C 

©  ©  © 

2  .52  o  c 

25  E  ©-  g 

o  ©  E  -E 

<  UJ  8  ■" 

© 

mm  © 


“O 

©  =. 

‘■6  © 
o  5 

E  8 

■“  k. 
^  *© 

©  £ 
©  m 
®  N 
©  *F 

-Q  S 
c  2 

s  s 

©  « 
©  o 

*©  © 
>  © 
i_  3 

&  © 
©  -£ 

il 

CL  < 


•  • 


E  E 
c  © 

7o£ 
c  *o 
-2  © 

5"° 
©  2 

o  g 

©  b 
.c  © 

-*-*  Q_ 

C  X 

o  © 

"O  © 
©  ” 
©  *— 

©  © 
■O  o 

w.E 

|c 

©  g 

§2 
© 
o  -* 

U-5 


CD 

©  V- 
>*  2 
55  f 

I  5 

© 


«  <0 
$  g 


o  <s 

©  O 


o  © 

~  -O  © 

£  ©  t- 

©  ©  © 
CO  ©  © 

•U  CD  3 
c 

2  •  • 


G-70 


28.1993 


k 


LL 

^  C 
CO  0 

II 

tr  5 

<  § 
0  0 

5  Q 

•*-  0 
°  > 

®  t5 

0  3 

55  E 
0  £ 

.>» 

"l  O) 

OL  X 
W  D) 

c  .£ 
©  .b= 
C  3 

£  Z 

a  CC 

S'-! 

CC  -Q 
LL  ® 

«  « 
t  t; 

O  £ 
O  CO 


0 

0 

0  ® 
o  0 

o  ® 

”1 

+3  O 

8  o 

0  C 
0  O 

0  N  *-53 
0  O 
0  E  C 
O  *F  3 
O  |  Q. 

CL  ^  *3 
§>1  | 
1 5  f 

£-J  © 

0^0 

>  So 

t3  0-  c 

£  5  3 

W  w  & 

O 


October  28, 1993 


E 

© 

>> 

© 

© 


© 

CO 

o 

o 

© 


© 


o 

I  © 

E  £ 

O  _F 
O  S 

.E  o 

©  J2>  g 

^  ro 
©  ”D  ■§ 
|«  8 
E  ®  c 
8  5  .2 

1*8 

°§ 

«  I  E 
«  2  E 

£  £  O 

8  •  • 


© 

© 

o 

© 


© 


©  E 

c  w 

.=  © 

/A  © 

co  © 
Q 
T3 


© 


© 

O) 


© 

< 

cr  ©  _ 

Q  D  Q. 


© 

o 


E 

© 

© 

© 


© 

© 

2 

o 

© 

JO 

© 

■D 

O 

E 


© 

c 

o 

E 

E 

o 

c  ^ 
©  CO 

E 


|  a  Je 
© 
CD 


© 

© 

i= 

o 

o 


*o 

c 

© 

O 

o 


© 

£ 

3 

© 

C 

111 


■ 

a 

o 

>* 

-Q 

© 

C 

© 

E 

© 


cr 

© 

cr 

“O 

c 

© 

•» 

W 

c 

O) 

©  © 
©  © 
3  O 
T3  - 
O  © 

2  c6 

■o  g 
©  zz 
c  o 
C  CO 
©  — 

2  § 

■O  E 

S I 

£8 

CO  o 


*o 

© 

~Q  N 

©  ‘E 
N 

1 1 

£  § 
.52  w 
©  .2 
©  — 
■D  g 
O  t3 
2  < 

*o 
c 


© 


© 


a  o. 

©  o 
Q  © 

4-  > 

O  © 

c  O 
.2  © 
5  g 

©  -M 

t  CL 
O  3 

o  a 


©  ■*- 
©  55 


8 


G-73 


28,1993 


G-74 


Ail  model  and  data  usage  is  traced  back  to  source  of  input  for 
consistency 
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CCTT  SAF  Openness  and  Traceability  Provides  the 
Basis  for  Future  Research  and  Development 
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Customizable:  Offline  CIS  Editor,  Edit  CIS  Parameters,  UCI  Customization 

Portable:  POSIX,  Standardized  Ada,  X  /  Motif,  no  Hardware 
Customizations 
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This  approach  allows  any  method  of  tactical  reasoning  providing  an  open 
design  for  multiple  vendor  solutions  ora  home-grown  solution 
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